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METHOD AND ARTICLE OF MANUFACTURE FOR PROVIDING A 
COMPONENT BASED INTERFACE TO HANDLE TASKS DURING 
CLAIM PROCESSING 

5 

FIELD OF THE INVENTION 

The present invention relates to task management and more particularly to 
handling task during insurance claim processing utilizing a computer system. 

10 

BACKGROUND OF THE INVENTION 

Computers have become a necessity in life today. They appear in nearly every 
office and household worldwide. A representative hardware environment is 

15 depicted in prior art Figure 1, which illustrates a typical hardware configuration 
of a workstation having a central processing unit 110, such as a microprocessor, 
and a number of other units interconnected via a system bus 112. The 
workstation shown in Figure 1 includes a Random Access Memory (RAM) 114, 
Read Only Memory (ROM) 116, an I/O adapter 118 for connecting peripheral 

20 devices such as disk storage units 120 to the bus 112, a user interface adapter 122 
for connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 132, 
and/or other user interface devices such as a touch screen (not shown) to the bus 
112, communication adapter 134 for connecting the workstation to a 
communication network (e.g., a data processing network) and a display adapter 

25 136 for connecting the bus 112 to a display device 138. The workstation 
typically has resident thereon an operating system such as the Microsoft 
Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating 
system, the MAC OS, or UNIX operating system. 

30 Object oriented programming (OOP) has become increasingly used to develop 
complex applications. As OOP moves toward the mainstream of software design 
and development, various software solutions require adaptation to make use of 
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the benefits of OOP. A need exists for these principles of OOP to be applied to a 
messaging interface of an electronic messaging system such that a set of OOP 
classes and objects for the messaging interface can be provided. 

5 OOP is a process of developing computer software using objects, including the 
steps of analyzing the problem, designing the system, and constructing the 
program. An object is a software package that contains both data and a collection 
of related structures and procedures. Since it contains both data and a collection 
of structures and procedures, it can be visualized as a self-sufficient component 
10 that does not require other additional structures, procedures or data to perform its 
specific task. OOP, therefore, views a computer program as a collection of 
largely autonomous components, called objects, each of which is responsible for 
a specific task. This concept of packaging data, structures, and procedures 
together in one component or module is called encapsulation. 

15 

In general, OOP components are reusable software modules which present an 
interface that conforms to an object model and which are accessed at run-time 
through a component integration architecture. A component integration 
architecture is a set of architecture mechanisms which allow software modules in 

20 different process spaces to utilize each others capabilities or functions. This is 
generally done by assuming a common component object model on which to 
build the architecture. It is worthwhile to differentiate between an object and a 
class of objects at this point. An object is a single instance of the class of objects, 
which is often just called a class. A class of objects can be viewed as a blueprint, 

25 from which many objects can be formed. 

OOP allows the programmer to create an object that is a part of another object. 
For example, the object representing a piston engine is said to have a 
composition-relationship with the object representing a piston. In reality, a piston 
30 engine comprises a piston, valves and many other components; the fact that a 
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piston is an element of a piston engine can be logically and semantically 
represented in OOP by two objects. 

OOP also allows creation of an object that "depends from" another object. If 
5 there are two objects, one representing a piston engine and the other representing 
a piston engine wherein the piston is made of ceramic, then the relationship 
between the two objects is not that of composition. A ceramic piston engine does 
not make up a piston engine. Rather it is merely one kind of piston engine that 
has one more limitation than the piston engine; its piston is made of ceramic. In 
10 this case, the object representing the ceramic piston engine is called a derived 
object, and it inherits all of the aspects of the object representing the piston 
engine and adds further limitation or detail to it. The object representing the 
ceramic piston engine "depends from" the object representing the piston engine. 
The relationship between these objects is called inheritance. 

15 

When the object or class representing the ceramic piston engine inherits all of the 
aspects of the objects representing the piston engine, it inherits the thermal 
characteristics of a standard piston defined in the piston engine class. However, 
the ceramic piston engine object overrides these ceramic specific thermal 

20 characteristics, which are typically different from those associated with a metal 
piston. It skips over the original and uses new functions related to ceramic 
pistons. Different kinds of piston engines have different characteristics, but may 
have the same underlying functions associated with it (e.g., how many pistons in 
the engine, ignition sequences, lubrication, etc.). To access each of these 

25 functions in any piston engine object, a programmer would call the same 
functions with the same names, but each type of piston engine may have 
different/overriding implementations of functions behind the same name. This 
ability to hide different implementations of a function behind the same name is 
called polymorphism and it greatly simplifies communication among objects. 



I 



With the concepts of composition-relationship, encapsulation, inheritance and 
polymorphism, an object can represent just about anything in the real world. In 
fact, the logical perception of the reality is the only limit on determining the kinds 
of things that can become objects in object-oriented software. Some typical 
categories are as follows: 

• Objects can represent physical objects, such as automobiles in a traffic- 
flow simulation, electrical components in a circuit-design program, 
countries in an economics model, or aircraft in an air-traffic-control 
system. 

• Objects can represent elements of the computer-user environment such as 
windows, menus or graphics objects. 

• An object can represent an inventory, such as a personnel file or a table of 
the latitudes and longitudes of cities. 

• An object can represent user-defined data types such as time, angles, and 
complex numbers, or points on the plane. 

With this enormous capability of an object to represent just about any logically 
separable matters, OOP allows the software developer to design and implement a 
computer program that is a model of some aspects of reality, whether that reality 
is a physical entity, a process, a system, or a composition of matter. Since the 
object can represent anything, the software developer can create an object which 
can be used as a component in a larger software project in the future. 

If 90% of a new OOP software program consists of proven, existing components 
made from preexisting reusable objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. Since 90% already 
came from an inventory of extensively tested reusable objects, the potential 
domain from which an error could originate is 10% of the program. As a result, 
OOP enables software developers to build objects out of other, previously built 
objects. 
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This process closely resembles complex machinery being built out of assemblies 
and sub-assemblies. OOP technology, therefore, makes software engineering 
more like hardware engineering in that software is built from existing 
5 components, which are available to the developer as objects. All this adds up to 
an improved quality of the software as well as an increased speed of its 
development. 
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SUMMARY OF THE INVENTION 

5 A computer program is provided for developing component based software 
capable of handling insurance-related tasks. The program includes a data 
component that stores, retrieves and manipulates data utilizing a plurality of 
functions. Also provided is a client component that includes an adapter 
component that transmits and receives data to/from the data component. The 

10 client component also includes a business component that serves as a data cache 
and includes logic for manipulating the data. A controller component is also 
included which is adapted to handle events generated by a user utilizing the 
business component to cache data and the adapter component to ultimately persist 
data to a data repository. In use, the client component is suitable for receiving a 

15 plurality of tasks that achieve an insurance-related goal upon completion, 

allowing users to add new tasks that achieve the goal upon completion, allowing 
the users to edit the tasks, and generating a historical record of the tasks that are 
completed. 



20 



DESCRIPTION OF THE DRAWINGS 



The foregoing and other objects, aspects and advantages are better understood 
from the following detailed description of a preferred embodiment of the 
invention with reference to the drawings, in which: 

Prior Art Figure 1 is a schematic diagram of the present invention; and 

Figure 2A is block diagram of one embodiment of the present invention. 

Figure 2B is a flowchart showing how components generally operate in 
accordance with one embodiment of the present invention. 

Figure 2C is a flowchart showing how the UI Controller operates in accordance 
with one embodiment of the present invention. 

Figure 2D is a flowchart showing the interactions between the CCA, the CCI, and 
the Server Component in accordance with one embodiment of the present 
invention. 

Figure 3 shows the life cycle of a typical User Interface and the standard methods 
that are part of the Window Processing Framework. 

Figure 4 is an illustration showing how different languages are repainted and 
recompiled. 

Figure 5 is a block diagram of an Architecture Object. 

Figure 6 is an illustration showing the physical layout of CodeDecode tables 
according to one embodiment of the present invention. 



Figure 7 is a logic diagram according to one embodiment of the present 
invention. 



5 Figure 8 is a block diagram of the security framework and its components. 

Figure 9 is an illustration showing the relationships between the security element 
and other elements. 

10 Figure 10 is an illustration of the Negotiation component of one embodiment of 
the present invention; 

Figure 11 is a flow diagram of the operations carried out by the Organization 
component of one embodiment of the present invention; 

15 

Figure 12 is an illustration of the Participant component of one embodiment of 
the present invention; 

Figure 13 is a flow diagram of the operations carried out by the Task Assistant 
20 component of one embodiment of the present invention; 

Figure 14 is an illustration of the Event Processor in combination with other 
components of the system in accordance with on embodiment of the present 
invention; and 

25 

Figure 15 is an illustration of the Task Engine in accordance with one 
embodiment of the present invention. 



DISCLOSURE OF THE INVENTION 



Programming languages are beginning to fully support the OOP principles, such 
as encapsulation, inheritance, polymorphism, and composition-relationship. With 
the advent of the C++ language, many commercial software developers have 
embraced OOP. C++ is an OOP language that offers a fast, machine-executable 
code. Furthermore, C++ is suitable for both commercial-application and 
systems-programming projects. For now, C++ appears to be the most popular 
choice among many OOP programmers, but there is a host of other OOP 
languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. 
Additionally, OOP capabilities are being added to more traditional popular 
computer programming languages such as Pascal. 

The benefits of object classes can be summarized, as follows: 

• Objects and their corresponding classes break down complex 
programming problems into many smaller, simpler problems. 

• Encapsulation enforces data abstraction through the organization of data 
into small, independent objects that can communicate with each other. 
Encapsulation protects the data in an object from accidental damage, but 
allows other objects to interact with that data by calling the object's 
member functions and structures. 

• Subclassing and inheritance make it possible to extend and modify objects 
through deriving new kinds of objects from the standard classes available 
in the system. Thus, new capabilities are created without having to start 
from scratch. 

• Polymorphism and multiple inheritance make it possible for different 
programmers to mix and match characteristics of many different classes 
and create specialized objects that can still work with related objects in 
predictable ways. 
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Class hierarchies and containment hierarchies provide a flexible 
mechanism for modeling real -world objects and the relationships among 
them. 

Libraries of reusable classes are useful in many situations, but they also 
have some limitations. For example: 

Complexity. In a complex system, the class hierarchies for related classes 
can become extremely confusing, with many dozens or even hundreds of 
classes. 

Flow of control. A program written with the aid of class libraries is still 
responsible for the flow of control (i.e., it must control the interactions 
among all the objects created from a particular library). The programmer 
has to decide which functions to call at what times for which kinds of 
objects. 

Duplication of effort. Although class libraries allow programmers to use 
and reuse many small pieces of code, each programmer puts those pieces 
together in a different way. Two different programmers can use the same 
set of class libraries to write two programs that do exactly the same thing 
but whose internal structure (i.e., design) may be quite different, 
depending on hundreds of small decisions each programmer makes along 
the way. Inevitably, similar pieces of code end up doing similar things in 
slightly different ways and do not work as well together as they should. 



Class libraries are very flexible. As programs grow more complex, more 
programmers are forced to reinvent basic solutions to basic problems over and 

25 over again. A relatively new extension of the class library concept is to have a 
framework of class libraries. This framework is more complex and consists of 
significant collections of collaborating classes that capture both the small scale 
patterns and major mechanisms that implement the common requirements and 
design in a specific application domain. They were first developed to free 

30 application programmers from the chores involved in displaying menus, 



windows, dialog boxes, and other standard user interface elements for personal 
computers. 

Frameworks also represent a change in the way programmers think about the 
interaction between the code they write and code written by others. In the early 
days of procedural programming, the programmer called libraries provided by the 
operating system to perform certain tasks, but basically the program executed 
down the page from start to finish, and the programmer was solely responsible 
for the flow of control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems with a program that 
executed in just one way. 

The development of graphical user interfaces began to turn this procedural 
programming arrangement inside out. These interfaces allow the user, rather than 
program logic, to drive the program and decide when certain actions should be 
performed. Today, most personal computer software accomplishes this by means 
of an event loop which monitors the mouse, keyboard, and other sources of 
external events and calls the appropriate parts of the programmer's code 
according to actions that the user performs. The programmer no longer 
determines the order in which events occur. Instead, a program is divided into 
separate pieces that are called at unpredictable times and in an unpredictable 
order. By relinquishing control in this way to users, the developer creates a 
program that is much easier to use. Nevertheless, individual pieces of the 
program written by the developer still call libraries provided by the operating 
system to accomplish certain tasks, and the programmer must still determine the 
flow of control within each piece after it's called by the event loop. Application 
code still "sits on top of the system. 

Even event loop programs require programmers to write a lot of code that should 
not need to be written separately for every application. The concept of an 
application framework carries the event loop concept further. Instead of dealing 
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with all the nuts and bolts of constructing basic menus, windows, and dialog 
boxes and then making these things all work together, programmers using 
application frameworks start with working application code and basic user 
interface elements in place. Subsequently, they build from there by replacing 
some of the generic capabilities of the framework with the specific capabilities of 
the intended application. 

Application frameworks reduce the total amount of code that a programmer has 
to write from scratch. However, because the framework is really a generic 
application that displays windows, supports copy and paste, and so on, the 
programmer can also relinquish control to a greater degree than event loop 
programs permit. The framework code takes care of almost all event handling 
and flow of control, and the programmer's code is called only when the 
framework needs it (e.g., to create or manipulate a proprietary data structure). 

A programmer writing a framework program not only relinquishes control to the 
user (as is also true for event loop programs), but also relinquishes the detailed 
flow of control within the program to the framework. This approach allows the 
creation of more complex systems that work together in interesting ways, as 
opposed to isolated programs, having custom code, being created over and over 
again for similar problems. 

Thus, as is explained above, a framework basically is a collection of cooperating 
classes that make up a reusable design solution for a given problem domain. It 
typically includes objects that provide default behavior (e.g., for menus and 
windows), and programmers use it by inheriting some of that default behavior 
and overriding other behavior so that the framework calls application code at the 
appropriate times. 



There are three main differences between frameworks and class libraries: 
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• Behavior versus protocol. Class libraries are essentially collections of 
behaviors that you can call when you want those individual behaviors in 
your program. A framework, on the other hand, provides not only 
behavior but also the protocol or set of rules that govern the ways in 
which behaviors can be combined, including rules for what a programmer 
is supposed to provide versus what the framework provides. 

• Call versus override. With a class library, the code the programmer 
instantiates objects and calls their member functions. It's possible to 
instantiate and call objects in the same way with a framework (i.e., to treat 
the framework as a class library), but to take full advantage of a 
framework's reusable design, a programmer typically writes code that 
overrides and is called by the framework. The framework manages the 
flow of control among its objects. Writing a program involves dividing 
responsibilities among the various pieces of software that are called by the 
framework rather than specifying how the different pieces should work 
together. 

• Implementation versus design. With class libraries, programmers reuse 
only implementations, whereas with frameworks, they reuse design. A 
framework embodies the way a family of related programs or pieces of 
software work. It represents a generic design solution that can be adapted 
to a variety of specific problems in a given domain. For example, a single 
framework can embody the way a user interface works, even though two 
different user interfaces created with the same framework might solve 
quite different interface problems. 

Thus, through the development of frameworks for solutions to various problems 
and programming tasks, significant reductions in the design and development 
effort for software can be achieved. A preferred embodiment of the invention 
utilizes HyperText Markup Language (HTML) to implement documents on the 
Internet together with a general-purpose secure communication protocol for a 
transport medium between the client and the Newco. HTTP or other protocols 



could be readily substituted for HTML without undue experimentation. 
Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 
1866: Hypertext Markup Language - 2.0" (Nov. 1995); and R. Fielding, H, 
Frystyk, T. Berners-Lee, J. Gettys and J.C. Mogul, "Hypertext Transfer Protocol 
- HTTP/1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a 
simple data format used to create hypertext documents that are portable from one 
platform to another. HTML documents are SGML documents with generic 
semantics that are appropriate for representing information from a wide range of 
domains. HTML has been in use by the World-Wide Web global information 
initiative since 1990. HTML is an application of ISO Standard 8879; 1986 
Information Processing Text and Office Systems; Standard Generalized Markup 
Language (SGML). 

To date, Web development tools have been limited in their ability to create 
dynamic Web applications which span from client to server and intemperate with 
existing computing resources. Until recently, HTML has been the dominant 
technology used in development of Web-based solutions. However, HTML has 
proven to be inadequate in the following areas: 

• Poor performance; 

• Restricted user interface capabilities; 

• Can only produce static Web pages; 

• Lack of interoperability with existing applications and data; and 

• Inability to scale. 

Sun Microsystem's Java language solves many of the client-side problems by: 

• Improving performance on the client side; 

• Enabling the creation of dynamic, real-time Web applications; and 

• Providing the ability to create a wide variety of user interface 
components. 
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With Java, developers can create robust User Interface (UI) components. Custom 
"widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and 
client-side performance is improved. Unlike HTML, Java supports the notion of 
client-side validation, offloading appropriate processing onto the client for 
5 improved performance. Dynamic, real-time Web pages can be created. Using the 
above-mentioned custom UI components, dynamic Web pages can also be 
created. 

Sun's Java language has emerged as an industry-recognized language for 
10 "programming the Internet." Sun defines Java as: "a simple, object-oriented, 
distributed, interpreted, robust, secure, architecture-neutral, portable, high- 
performance, multithreaded, dynamic, buzzword-compliant, general-purpose 
programming language. Java supports programming for the Internet in the form 
of platform-independent Java applets." Java applets are small, specialized 
15 applications that comply with Sun's Java Application Programming Interface 
(API) allowing developers to add "interactive content" to Web documents (e.g., 
simple animations, page adornments, basic games, etc.). Applets execute within 
a Java-compatible browser (e.g., Netscape Navigator) by copying code from the 
server to client. From a language standpoint, Java's core feature set is based on 
20 C++. Sun's Java literature states that Java is basically, "C++ with extensions 
from Objective C for more dynamic method resolution." 

Another technology that provides similar function to JAVA is provided by 
Microsoft and ActiveX Technologies, to give developers and Web designers 

25 wherewithal to build dynamic content for the Internet and personal computers. 
ActiveX includes tools for developing animation, 3-D virtual reality, video and 
other multimedia content. The tools use Internet standards, work on multiple 
platforms, and are being supported by over 100 companies. The group's building 
blocks are called ActiveX Controls, small, fast components that enable 

30 developers to embed parts of software in hypertext markup language (HTML) 
pages. ActiveX Controls work with a variety of programming languages 
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including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic 
programming system and, in the future, Microsoft's development tool for Java, 
code named "Jakarta." ActiveX Technologies also includes ActiveX Server 
Framework, allowing developers to create server applications. One of ordinary 
skill in the art readily recognizes that ActiveX could be substituted for JAVA 
without undue experimentation to practice the invention. 

Detailed Description 

One embodiment of the present invention is a server based framework utilizing 
component based architecture. Referring to Figure 2A, one embodiment of the 
present invention includes an Architecture Object 200, an Application Object 
202, a User Interface Form 204, a User Interface Controller 206, a Client 
Component Adapter 208, a COM Component Interface 210, and a Server 
Component 222. 

In general, the components of the present invention operate as shown in Figure 
2B. In step 230, data is stored in an object of the component. In step 232, 
functions which manipulate the object are encapsulated with the object data. 
Later, in step 234, the stored object data can be manipulated by other components 
utilizing the functions of step 232. 

Architecture Object 

The Architecture Object 200 provides an easy-to-use object model that masks the 
complexity of the architecture on the client. The Architecture Object 200 
provides purely technical services and does not contain any business logic or 
functional code. It is used on the client as the single point of access to all 
architecture services. 

On the server side, the Architecture Object 200 is supplemented by a set of global 
functions contained in standard VB modules 
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The Architecture Object 200 is responsible for providing all client architecture 
services (i.e., codes table access, error logging, etc.), and a single point of entry 
for architecture services. The Architecture Object 200 is also responsible for 
5 allowing the architecture to exist as an autonomous unit, thus allowing internal 
changes to be made to the architecture with minimal impact to application. 

The Architecture Object 200 provides a code manager, client profile, text 
manager, ID manager, registry manager, log manager, error manager, and a 

10 security manager. The codes manager reads codes from a local database on the 
client, marshals the codes into objects, and makes them available to the 
application. The client profile provides information about the current logged-in 
user. The text manager provides various text manipulation services such as 
search and replace. The ID manager generates unique IDs and timestamps. The 

15 registry manager encapsulates access to the system registry. The log manager 
writes error or informational messages to the message log. The error manager 
provides an easy way to save and re-raise an error. And the security manager 
determines whether or not the current user is authorized to perform certain 
actions. 

20 

Application Object 

The Application Object 202 has a method to initiate each business operation in 
the application. It uses late binding to instantiate target UI controllers in order to 
25 provide autonomy between windows. This allows different controllers to use the 
Application Object 202 without statically linking to each and every UI controller 
in the application. 

When opening a UI controller, the Application Object 202 calls the architecture 
30 initialization, class initialization, and form initialization member functions. 



The Application Object 202 keeps a list of every active window, so that it can 
shut down the application in the event of an error. When a window closes, it tells 
the Application Object 202 , and is removed from the Application Object's 202 
list of active windows. 

The Application Object 202 is responsible for instantiating each UI Controller 
206, passing data / business context to the target UI Controller 206, and invoking 
standard services such as initialize controller, initializing Form and Initialize 
Architecture. The Application Object 202 also keeps track of which windows are 
active so that it can coordinate the shutdown process. 

UI Form 

The UI form's 204 primary responsibility is to forward important events to its 
controller 206. It remains mostly unintelligent and contains as little logic as 
possible. Most event handlers on the form simply delegate the work by calling 
methods on the form's controller 206. 

The UI form 204 never enables or disables its own controls, but ask its controller 
206 to do it instead. Logic is included on the UI form 204 only when it involves 
very simple field masking or minor visual details. 

The UI form 204 presents an easy-to-use, graphical interface to the user and 
informs its controller 206 of important user actions. The UI form 204 may also 
provide basic data validation (e.g., data type validation) through input masking. 
In addition, the UI form is responsible for intelligently resizing itself, launching 
context-sensitive help, and unload itself. 

User Interface Controller 

Every UI Controller 206 includes a set of standard methods for initialization, 
enabling and disabling controls on its UI form 204, validating data on the form, 
getting data from the UI form 204, and unloading the UI form 204. 
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UI Controllers 206 contain the majority of logic to manipulate Business Objects 
207 and manage the appearance of its UI form 204. If its form is not read-only, 
the UI Controller 206 also tracks whether or not data on the UI form 204 has 
changed, so as to avoid unnecessary database writes when the user decides to 
save. In addition, controllers of auxiliary windows (like the File-Save dialog box 
in Microsoft Word), keep track of their calling UI controller 206 so that they can 
notify it when they are ready to close. 

Figure 2C is a flowchart showing how the UI Controller operates in one 
embodiment of the present invention. In step 236, data is entered in a UI form by 
a user. In step 238, the UI controller interprets the data entered into the UI form. 
In step 240, the UI controller places the appropriate data into a Business Object to 
be utilized and retrieved later. 

A UI Controller 206 defines a Logical Unit of Work (LUW). If an LUW 
involves more than one UI Controller 206, the LUW is implemented as a separate 
object. 

The UI Controller 206 is responsible for handling events generated by the user 
interacting with the UI form 204 and providing complex field validation and 
cross field validation within a Logical Unit of Work. The UI Controller 206 also 
contains the logic to interact with business objects 207, and creates new business 
objects 207 when necessary. Finally, the UI Controller 206 interacts with Client 
Component Adapters 208 to add, retrieve, modify, or delete business objects 207, 
and handles all client-side errors. 

Business Objects 

The Business Object's (BO) 207 primary functionality is to act as a data holder, 
allowing data to be shared across User Interface Controllers 206 using an object- 
based programming model. 
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BOs 207 perform validation on their attributes as they are being set to maintain 
the integrity of the information they contain. BOs 207 also expose methods other 
than accessors to manipulate their data, such as methods to change the life cycle 
5 state of a BO 207 or to derive the value of a calculated attribute. 

In many cases, a BO 207 will have its own table in the database and its own 
window for viewing or editing operations. 

10 Business Objects 207 contain information about a single business entity and 
maintain the integrity of that information. The BO 207 encapsulates business 
rules that pertain to that single business entity and maintains relationships with 
other business objects (e.g., a claim contains a collection of supplements). 
Finally, the BO 207 provides additional properties relating to the status of the 

15 information it contains (such as whether that information has changed or not), 
provides validation of new data when necessary, and calculates attributes that are 
derived from other attributes (such as Full Name, which is derived from First 
Name, Middle Initial, and Last Name). 

20 Client Component Adapters 

Client Component Adapters (CCAs) 208 are responsible for retrieving, adding, 
updating, and deleting business objects in the database. CCAs 208 hide the 
storage format and location of data from the UI controller 206. The UI controller 
206 does not care about where or how objects are stored, since this is taken care 
25 of by the CCA 208. 

The CCA 208 marshals data contained in recordsets returned by the server into 
business objects 207. CCAs 208 masks all remote requests from UI Controller 
206 to a specific component, and act as a "hook" for services such as data 
30 compression, and data encryption. 



COM Component Interface 

A COM Component Interface (CCI) 210 is a "contract" for services provided by 
a component. By "implementing" an interface (CCI) 210, a component is 
promising to provide all the services defined by the CCI 20. 

The CCI 210 is not a physical entity (which is why it is depicted with a dotted 
line). It's only reason for existence is to define the way a component appears to 
other objects. It includes the signatures or headers of all the public properties or 
methods that a component will provide. 

To implement a CCI 210, a server component exposes a set of specially named 
methods, one for each method defined on the interface. These methods should do 
nothing except delegate the request to a private method on the component which 
will do the real work. 

The CCI 210 defines a set of related services provided by a component. The CCI 
allows any component to "hide" behind the interface to perform the services 
defined by the interface by "implementing" the interface. 

Server Component 

Server components 222 are course grained and transaction oriented. They are 
designed for maximum efficiency. 

Server Components 222 encapsulate all access to the database, and define 
business transaction boundaries. In addition, Server Components 222 are 
responsible for ensuring that business rules are honored during data access 
operations. 

A Server Component 222 performs data access operations on behalf of CCAs 
208 or other components and participates in transactions spanning server 
components 222 by communicating with other server components 222 . The 
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Server Component 222 is accessible by multiple front end personalities (e.g., 
Active Server Pages), and contains business logic designed to maintain the 
integrity of data in the database. 

5 Figure 2D is a flowchart showing the interactions between the CCA, the CCI, and 
the Server Component in accordance with one embodiment of the present 
invention. In step 242, a request is made to place client created data on the server 
database. In step 244, the data is transferred to the server component 222 
utilizing a CCI 210. In step 246, the server component 222 stores the data in the 

10 server database. 



BUSINESS RULE PLACEMENT 



15 Overview 

The distribution of business rules across tiers of the application directly affects 
the robustness and performance of the system as a whole. Business rules can be 
categorized into the following sections: Relationships, Calculations, and Business 
Events. 

20 Relationships between Business Objects 

Business Objects 207 are responsible for knowing other business objects 207 
with which they are associated. 

Relationships between BOs 207 are built by the CCA 208 during the marshaling 
25 process. For example, when a CCA 208 builds a claim BO 207, it will also build 
the collection of supplements if necessary. 

Calculated Business Data 

Business rules involving calculations based on business object 207 attributes are 
coded in the business objects 207 themselves. Participant Full Name is a good 
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example of a calculated attribute. Rather than force the controllers to concatenate 
the first name, middle initial, and last name every time they wanted to display the 
full name, a calculated attribute that performs this logic is exposed on the 
business object. In this way, the code to compose the full name only has to be 
5 written once and can be used by many controllers 206. 

Another example of a calculated attribute is the display date of a repeating task. 
When a task with a repeat rule is completed, a new display date must be 
determined. This display date is calculated based on the date the task was 
10 completed, and the frequency of repetition defined by the repeat rule. Putting the 
logic to compute the new display date into the Task BO 207 ensures that it is 
coded only once. 

Responses to Business Events 

Business rules that relate to system events and involve no user interaction are 
15 enforced on the server components. 

Completion of a task is a major event in the system. When a task is completed, 
the system first ensures that the performer completing the task is added to the 
claim. Then, after the task is marked complete in the database, it is checked to 
20 see if the task has a repeat rule. If so, another task is created and added to the 

database. Finally, the event component is notified, because the Task Engine may 
need to react to the task completion. 

Consider the scenario if the logic to enforce this rule were placed on the UI 
25 controller 206. 

The controller 206 calls the Performer Component to see if the performer 
completing the task has been added to the claim. If the performer has not been 
added to the claim, then the controller 206 calls the performer component again 
30 to add them. 
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Next, the controller 206 calls the Task Component to mark the task complete in 
the database. If the task has a repeat rule, the controller 206 computes the date 
the task is to be redisplayed and calls the Task Component again to add a new 
5 task. Lastly, the controller 206 calls the Event Component to notify the Task 
Engine of the task completion. 

The above implementation requires five network round trips in its worst case. In 
addition, any other controller 206 or server component 222 that wants to 
10 complete a task must code this logic all over again. Enforcing this rule in the task 
server component 222 reduces the number of network round trips and eliminates 
the need to code the logic more than once. 

Responses to User Events 

All responses to user events are coordinated by the controller 206. The controller 
15 206 is responsible for actions such as enabling or disabling controls on its form, 
requesting authorization from the security component, or making calls to the 
CCA 208. 

Authorization 

All logic for granting authorization is encapsulated inside the security 
20 component. Controllers 206 and components 222 must ask the security 

component if the current user is authorized to execute certain business operations 
in the system. The security component will answer yes or no according to some 
predefined security logic. 



Summary 



Tvpe of Business Rule 


Example 


Responsibility 


Maintaining relationships 
between BOs 


Claim keeps a collection of supplements 


Business Objects 


Building relationships 
between BOs 


CCA builds the claim's collection of 
supplements 


CCAs 


Calculated Business Data 


Participant calculates its full name 


Business Objects 


Responses to Business 


Task Component collaborates with other 


Components 
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Events 


components 




Requesting Authorization 


Task Library controller asks the security 
component if the current user is allowed 
to access Task Library 


Controllers and 
Components 


Granting Authorization 


Security component determines whether 
or not the current user can access Task 
Library 


Security Component 



WINDOW PROCESSING FRAMEWORK 

The Default Window Framework provides default window processing for each 
window contained within the system. This default processing aides the developer 
in developing robust, maintainable UIs, standardizes common processes (such as 
form initialization) and facilitates smooth integration with architecture services. 

10 

Figure 3 shows the life cycle of a typical User Interface and the standard methods 
that are part of the Window Processing Framework 300. 

The Window Processing Framework 300 encompasses the following: 
15 Window Initialization 302; 
Window Save Processing 304; 
Window Control State Management 306; 
Window Data Validation 308; 
Window Shutdown Processing 310. 

20 

Window Initialization Processing 302: After creating a controller 206 for the 
desired window, the App object 202 calls a set of standard initialization functions 
on the controller 206 before the form 204 is displayed to the user. Standardizing 
these functions makes the UIs more homogeneous throughout the application, 
25 while promoting good functional decomposition. 
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Window Save Processing 304: Any time a user updates any form text or adds 
an item to a ListBox, the UI Controller 206 marks the form as "dirty". This 
allows the UI controller 206 to determine whether data has changed when the 
form closes and prompt the user to commit or lose their changes. 

Window Control State Management 306: Enabling and disabling controls and 
menu options is a very complex part of building a UI. The logic that modifies the 
state of controls is encapsulated in a single place for maintainability. 

Window Data Validation 308: Whenever data changes on a form, validation 
rules can be broken. The controller is able to detect those changes, validate the 
data, and prompt the user to correct invalid entries. 

Window Shutdown Processing 310: The Window Shutdown framework 
provides a clear termination path for each UI in the event of an error. This 
reduces the chance of memory leaks, and General Protection failures. 



Benefits 

Standardized Processing: Standardizing the window processing increases the 
homogeneity of the application. This ensures that all windows within the 
application behave in a consistent manner for the end users, making the 
application easier to use. It also shortens the learning curve for developers and 
increases maintainability, since all windows are coded in a consistent manner. 

Simplified Development: Developers can leverage the best practices 
documented in the window processing framework to make effective design and 
coding decisions. In addition, a shell provides some "canned" code that gives 
developers a head start during the coding effort. 
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Layered Architecture: Because several architecture modules provide 
standardized processing to each application window, the core logic can be 
changed for every system window by simply making modifications to a single 
procedure. 

5 

Window Initialization 302 

To open a new window, the App Object 202 creates the target window's 
controller 206 and calls a series of methods on the controller 206 to initialize it. 
The calling of these methods, ArchlnitClass, InitClass, InitForm, and ShowForm, 
10 is illustrated below. 

ArchlnitClass 

The main purpose of the ArchlnitClass function is to tell the target controller 206 
who is calling it. The App Object 202 "does the introductions" by passing the 
15 target controller 206 a reference to itself and a reference to the calling controller 
206. In addition, it serves as a hook into the controller 206 for adding 
architecture functionality in the future. 

Public Sub ArchlnitClass (objApp As Object, objCallingCTLR As 
20 Object) 

' remember who called me 
Set m__objApp = objApp 

Set m_objCallingCTLR = objCallingCTLR 
End Sub 

25 InitClass 

This function provides a way for the App Object 202 to give the target controller 
206 any data it needs to do its processing. It is at this point that the target 
controller 206 can determine what "mode" it is in. Typical form modes include, 
add mode, edit mode, and view mode. If the window is in add mode, it creates a 
30 new BO 207 of the appropriate type in this method. 

Public Sub InitClass (colPrevSelection As CArchCollection) 

If colPrevSelection Is Nothing Then 

' no accounts were previously selected 
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Set m_colPrevSelection = New CArchCol lection 
Set m_colNewSelection = New CArchCol lection. 

Else 

' some accounts may have already been selected 
5 Set m_colPrevSelection = colPrevSelection 

Set m__colNewSelection = colPrevSelection . Clone ( ) 
End If 

Set m_colResults = New CArchCollection 

10 

DetermineFormMode { ) 
End Sub 

InitForm 

The InitForm procedure of each controller 206 coordinates any initialization of 
15 the form 204 before it is displayed. Because initialization is often a multi-step 
process, InitForm creates the window and then delegates the majority of the 
initialization logic to helper methods that each have a single purpose, in order to 
follow the rules of good functional decomposition. For example, the logic to 
determine a form's 204 state based on user actions and relevant security 
20 restrictions and move to that state is encapsulated in the DetermineFormState 
method. 

Public Sub XnitForm() 

x create my form 
25 Set m_f rmCurrentForm = New f rmAccountSearch 

' figure out the state of my form based on arguments I 
received in InitClass and 

1 enable/disable the appropriate controls 
DetermineFormState ( ) 
30 ' fill my form with data 

PopulateForm ( ) 
End Sub 



PopulateForm 

35 PopulateForm is a private method responsible for filling the form with data 
during initialization. It is called exactly once by the InitForm method. 
PopulateForm is used to fill combo boxes on a form 204, get the details of an 
object for an editing window, or display objects that have already been selected 
by the user, as in the following example. 



40 
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Private Sub PopulateForm( ) 

Dim acct As CAccount 
Dim item As GTListltem 

' display any accounts already selected by the user 
■ create and add a Listltem for every Account in the 
previous selection collection 

With f rmCurrentForm. lvwResults .Listltems 
.Clear 

For Each acct In m_colPrevSelection 

Set item = .Add(, acct. Number, acct. Number) 
item. Subl terns (1) = acct. Name 

Next 
End With 
End Sub 

ShowForm 

The ShowForm method simply centers and displays the newly initialized form 
204. 

Public Sub ShowFormO 

' center my form 

f rmCurrentForm . Move ( Screen . Width 

2,_ 

(Screen. Height 

/ 2 

■ display my form 
f rmCurrentForm. Show vbModal 
End Sub 



Window Control State Management 306 

It is often necessary to enable or disable controls on a form 204 in response to 
user actions. This section describes the patterns employed by the Component 
Based Architecture for MTS (CBAM) to manage this process effectively. 

Form Mode 

It is helpful to distinguish between form mode and form state. Form mode 
indicates the reason the form 204 has been invoked. Often, forms 204 are used 
for more than one purpose. A common example is the use of the same form to 
view, add, and edit a particular type of object, such as a task or an insurance 
claim. In this case, the form's modes would include View, Add, and Update. 



- f rmCurrentForm. Width) / 
- f rmCurrentForm. Height) 
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The modes of a form 204 are also used to comply with security restrictions based 
on the current user's access level. For example, Task Library is a window that 
limits access to task templates based on the current user's role. It might have a 
5 Librarian mode and a Non-Librarian mode to reflect the fact that a non-librarian 
user cannot be allowed to edit task templates. In this way, modes help to enforce 
the requirement that certain controls on the form 204 remain disabled unless the 
user has a certain access level. 

10 It is not always necessary for a form 204 to have a mode; a form might be so 
simple that it would have only one mode - the default mode. In this case, even 
though it is not immediately necessary, it may be beneficial to make the form 
"mode-aware" so that it can be easily extended should the need arise. 

Form State 

15 A form 204 will have a number of different states for each mode, where a state is 
a unique combination of enabled/disabled, visible/invisible controls. When a 
form 204 moves to a different state, at least one control is enabled or disabled or 
modified in some way. 

20 A key difference between form mode and form state is that mode is determined 
when the controller 206 is initialized and remains constant until the controller 
206 terminates. State is determined when the window initializes, but is 
constantly being reevaluated in response to user actions. 

Handling VI Events 

25 When the value of a control on the form 204 changes, it is necessary to reevaluate 
the state of the controls on the form (whether or not they are enabled/disabled or 
visible/invisible, etc.). If changing the value of one control could cause the state 
of a second control to change, an event handler is written for the appropriate 
event of the first control. 



The following table lists common controls and the events that are triggered when 
their value changes. 



Control 


Event 


TextBox 


Change 


ComboBox 


Change 


ListBox 


Click 


CheckBox 


Click 


Option Button 


Click 



5 



The event handler calls the DetermineFormState method on the controller 206. 
Setting the State of Controls 

It is essential for maintainability that the process of setting the state of controls be 
separate from the process for setting the values of those controls. The 
10 DetermineFormState method on the controller 206 forces this separation between 
setting the state of controls and setting their values. 

DetermineFormState is the only method that modifies the state of any of the 
controls on the form 204. Because control state requirements are so complex and 
15 vary so widely, this is the only restriction made by the architecture framework. 

If necessary, parameters are passed to the DetermineFormState function to act as 
"hints" or "clues" for determining the new state of the form 204. For complex 
forms, it is helpful to decompose the DetermineFormState function into a number 
20 of helper functions, each handling a group of related controls on the form or 
moving the form 204 to a different state. 
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Example 

The Edit/ Add/View Task Window has three modes: Edit, Add, and View. In 
Add mode, everything on the form is editable. Some details will stay disabled 
when in Edit mode, since they should be set only once when the task is added. In 
both Add and Edit modes, the repeat rule may be edited. Enabling editing of the 
repeat rule always disables the manual editing of the task's due and display dates. 
In View mode, only the Category combo box and Private checkbox are enabled. 



v Edit /Add/ View Task Form 
Private Sub txtName_Change ( ) 

myController .DetermineFormState 
End Sub 

1 Edit/Add/View Task Controller 
Public Sub DetermineFormState ( ) 

On Error Goto ErrorHandler 
Select Case m_nForrtiMode 

' In Edit Mode, enable only "editable" details and 
Repeat Rule editing if necessary 
Case cmFormModeEdit 

EnableAddDetails False 
EnableEditDetails True 
EnableViewDetails True 

If m_frmCurrentForm.chkRepetetiveTask. Checked Then 
EnableEditRepeatRule True 
EnableEditDisplayDueDates False 

Else 

EnableEditRepeatRule False 
EnableEditDisplayDueDates True 
End If 

If m_nFormDirty Then EnableSave True Else 
EnableSave False 

1 In Add Mode, enable all details and Repeat Rule 
editing if necessary 

Case cmFormModeAdd 

EnableAddDetails True 
EnableEditDetails True 
EnableViewDetails True 

If m _frmCurrentForm.chkRepetetiveTask. Checked Then 
EnableEditRepeatRule True 
EnableEditDisplayDueDates False 

Else 

EnableEditRepeatRule False 
EnableEditDisplayDueDates True 
End If 
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If m_nFormDirty Then EnableSave True Else 
EnableSave False 

* In View Mode, disable everything except a few 

details 

Case cmFormModeView 

EnableAddDetails False 
EnableEditDetails False 
EnableViewDetails True 
EnableEditRepeatRule False 
EnableEditDisplayDueDates False 
EnableSave False 
Case Else 
End Select 
Exit Sub 
ErrorHandler : 

' error handling 
End Sub 



* Edit/Add/View Task Controller 

Private Sub EnableAddDetails (bYesNo As Boolean) 

On Error Goto ErrorHandler 

1 Enable or disable controls that should be available only 
when the task is being added. 
With frmCurrentForm 

.Name . Enabled = bYesNo 
.Description. Enabled = bYesNo 
.Type. Enabled - bYesNo 
.Level . Enabled = bYesNo 
.Source. Enabled = bYesNo 
End With 
Exit Sub 
ErrorHandler: 

1 error handling logic 
End Sub 



Window Data Validation 308 

Window data validation is the process by which data on the window is examined 
for errors, inconsistencies, and proper formatting. It is important, for the sake of 
consistency, to implement this process similarly or identically in all windows of 
the application. 
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Types of Validation 

Input Masking 

Input masking is the first line of defense. It involves screening the data (usually 
character by character) as it is entered, to prevent the user from even entering 
invalid data. Input masking may be done programmatically or via a special 
masked text box, however the logic is always located on the form, and is invoked 
whenever a masked field changes. 

Single-Field Range Checking 

Single-field range checking determines the validity of the value of one field on 
the form by comparing it with a set of valid values. Single-field range checking 
may be done via a combo box, spin button, or programmatically on the form, and 
is invoked whenever the range-checked field changes. 

Cross-Field Validation 

Cross-field validation compares the values of two or more fields to determine if a 
validation rule is met or broken, and occurs just before saving (or searching). 
Cross-field validation may be done on the Controller 206 or the Business Object 
207, however it is preferable to place the logic on the Business Object 207 when 
the validation logic can be shared by multiple Controllers 206. 

Invalid data is caught and rejected as early as possible during the input process. 
Input masking and range checking provide the first line of defense, followed by 
cross-field validation when the window saves (or searches). 

Single-Field Validation 

All single-field validation is accomplished via some sort of input masking. 
Masks that are attached to textboxes are used to validate the type or format of 
data being entered. Combo boxes and spin buttons may also be used to limit the 
user to valid choices. If neither of these are sufficient, a small amount of logic 
may be placed on the form's event handler to perform the masking functionality, 
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such as keeping a value below a certain threshold or keeping apostrophes out of a 
textbox. 

Cross-Field Validation 

When the user clicks OK or Save, the form calls the IsFormDataValid on the 
controller to perform cross-field validation (e.g., verifying that a start date is less 
than an end date). If the business object 207 contains validation rules, the 
controller 206 may call a method on the business object 207 to make sure those 
rules are not violated. 

If invalid data is detected by the controller 206, it will notify the user with a 
message box and, if possible, the indicate which field or fields are in error. 
Under no circumstances will the window perform validation when the user is 
trying to cancel. 

Example 

" Generic Edit Form 
Private Sub cmdOK_Click ( ) 

On Error Goto ErrorHandler 

' shut down if my data is valid. 

* saving/ canceling will occur in my controller's 
QueryUnload function 

If IsFormDataValid Then Unload Me 

Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
End Sub 

Public Function IsFormDataValid ( ) As Boolean 

On Error Goto ErrorHandler 

1 assume success 
IsFormDataValid = True 

* evaluate all validation rules 
With f rmCurrentForm 

' make sure start date is earlier than end date 
If . txtStartDate.Text > . txtEndDate . Text Then 

IsFormDataValid = False 

MsgBox cmMsglnvalidEndDate 

. txtEndDate . SetFocus 
Elself . . . 
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v more validation rules 
End If 
End With 

Exit Function 
ErrorHandler : 

1 error handling logic 
End Function 

Window Save Processing 304 

Window "Save Processing" involves tracking changes to data on a form 204 and 
responding to save and cancel events initiated by the user. 

Tracking Changes to Form Data 

Each window within the CB AM application contains a field within its 
corresponding control object known as the dirty flag. The dirty flag is set to True 
whenever an end user modifies data within the window. This field is interrogated 
by the UI Controller 206 to determine when a user should be prompted on Cancel 
or if a remote procedure should be invoked upon window close. 

The application shell provides standard processing for each window containing 
an OK or Save button. 

Saving 

The default Save processing is implemented within the UI Controller 206 as 
follows: 

The UI Controller is Notified that the OK button has been clicked. Then the 
controller 206 checks its Dirty Flag. If flag is dirty, the controller 206 calls the 
InterrogateForm method to retrieve data from the form 204 and calls a server 
component 222 to store the business object 207 in the database. If the Dirty Flag 
is not set, then no save is necessary. The window is then closed. 
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Canceling 

When the user cancels a window, the UI Controller 206 immediately examines 
the Dirty Flag. If the flag is set to true, the user is prompted that their changes 
will be lost if they decide to close the window. 

Once prompted, the user can elect to continue to close the window and lose their 
changes or decide not to close and continue working. 



Window Shutdown Processing 310 

In the event of an error, it is sometimes necessary to shutdown a window or to 
terminate the entire application. It is critical that all windows follow the 
15 shutdown process in order to avoid the GPFs commonly associated with 

terminating incorrectly. Following is how the window/application is shutdown. 

Shutdown Scope 

The scope of the shutdown is as small as possible. If an error occurs in a 
controller 206 that does not affect the rest of the application, only that window is 
20 shut down. If an error occurs that threatens the entire application, there is a way 
to quickly close every open window in the application. The window shutdown 
strategy is able to accommodate both types of shutdowns. 
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Shutdown 

In order to know what windows must be shut down, the architecture tracks which 
windows are open. Whenever the App Object 202 creates a controller 206, it 
calls its RegCTLR function to add the controller 206 to a collection of open 
5 controllers. Likewise, whenever a window closes, it tells the App Object 202 that 
it is closing by calling the App Object's 202 UnRegCTLR function, and the App 
Object 202 removes the closing controller 206 from its collection. In the case of 
an error, the App Object 202 loops through its collection of open controllers, 
telling each controller to "quiesce" or shutdown immediately. 

10 GeneralErrorHandler 

The GeneralErrorHandler is a method in MArch.bas that acts as the point of entry 
into the architecture's error handling mechanism. A component or a controller 
will call the GeneralErrorHandler when they encounter any type of unexpected or 
unknown error. The general error handler will return a value indicating what the 
15 component or controller should do: (1) resume on the line that triggered the error 
(2) resume on the statement after the line that triggered the error (3) exit the 
function (4) quiesce (5) shutdown the entire application. 

ErrorHandler : 
20 Select Case CStr (Err .Number) 

* handle a search with no result error 
Case cmErrNoClaimTreeData 

MsgBox cmMsgNoResultsQuery, vblnf ormation 
frmCurrentForm. StatusBar. Panels (1) = 
25 cmNoResultsQuery 

'Sets mouse pointer back to default 
frmCurrentForm. MousePointer = vbDefault 
Case Else 

Dim nResumeCode As Integer 
30 nResumeCode = 

GeneralErrorHandler (obj App. obj Arch. AsMsgStruct, cmController , 

cmClassName, 

cmMethodName ) 
35 Select Case CStr (nResumeCode) 

Case cmErrorResume 

Resume 
Case cmErrorResumeNext 
Resume Next 
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Case cmErrorExit 

Exit Sub 
Case cmErrorQuiesce 

Quiesce 
Case Else 

obj App . Shutdown 
End Select 
End Select 
End Sub 

In order to prevent recursive calls the GeneralErrorHandler keeps a collection of 
controllers that are in the process of shutting down. If it is called twice in a row 
by the same controller 206, it is able to detect and short-circuit the loop. When 
the controller 206 finally does terminate, it calls the UnRegisterError function to 
let the GeneralErrorHandler know that it has shut down and removed from the 
collection of controllers. 

Shutdown Process 

After being told what to do by the GeneralErrorHandler, the controller 206 in 
error may try to execute the statement that caused the error, proceed as if nothing 
happened, exit the current function, call its Quiesce function to shut itself down, 
or call the Shutdown method on the App Object 202 to shut the entire application 
down. 



Additional Standard Methods 

Searching 

Controllers 206 that manage search windows have a public method named 
Find<Noun>s where <Noun> is the type of object being searched for. This 
method is called in the event handler for the Find Now button. 
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Saving 

Any controller 206 that manages an edit window has a public method called Save 
that saves changes the user makes to the data on the form 204. This method is 
called by the event handlers for both the Save and OK buttons (when/if the OK 
5 button needs to save changes before closing). 

Closing 

A VB window is closed by the user in several ways: via the control-box in upper 
left corner, the X button in upper right corner, or the Close button. When the 
form closes, the only method that will always be called, regardless of the way in 
10 which the close was initiated, is the form' s 204 QueryUnload event handler. 

Because of this, there cannot be a standard Close method. Any processing that 
must occur when a window closes is to be done in the QueryUnload method on 
the controller 206 (which is called by the form's QueryUnload event handler). 

15 

The VB statement, Unload Me, appears in the Close button's event handler to 
manually initiate the unloading process. In this way, the Close button mimics the 
functionality of the control box and the X button, so that the closing process is 
handled the same way every time, regardless of how the user triggered the close. 
20 The OK button's event handler also executes the Unload Me statement, but calls 
the Save method on the controller first to save any pending changes. 

BUSINESS OBJECTS 

25 

Business Objects 207 are responsible for containing data, maintaining the 
integrity of that data, and exposing functions that make the data easy to 
manipulate. Whenever logic pertains to a single BO 207 it is a candidate to be 
placed on that BO. This ensures that it will not be coded once for each controller 
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206 that needs it. Following are some standard examples of business object 
logic. 

Business Logic: Managing Life Cycle State 

Overview 

The "state" of a business object 207 is the set of all its attributes. Life cycle state 
refers only to a single attribute (or a small group of attributes) that determine 
where the BO 207 is in its life cycle. For example, the life cycle states of a Task 
are Open, Completed, Cleared, or Error. Business objectives usually involve 
moving a BO toward its final state (i.e., Completed for a Task, Closed for a 
Supplement, etc.). 

Often, there are restrictions on a BO's movement through its life cycle. For 
example, a Task may only move to the Error state after first being Completed or 
Cleared. BOs provide a mechanism to ensure that they do not violate life cycle 
restrictions when they move from state to state. 

Approach 

A BO 207 has a method to move to each one of its different life cycle states. 
Rather than simply exposing a public variable containing the life cycle state of 
the task, the BO exposes methods, such as Task.Clear(), Task.Complete(), and 
Task.MarklnErrorO, that move the task a new state. This approach prevents the 
task from containing an invalid value for life cycle state, and makes it obvious 
what the life cycle states of a task are. 

Example 

x CTask Business Object 
Public Sub MarklnError ( ) 

On Error Goto ErrorHandler 

Select Case m_nLif eCycleState 

* move to error only if I've already been completed or 

cleared 

Case cmTaskCompleted, cmTaskCleared 
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m_nLif eCycleState = cmTasklnError 
1 otherwise, raise an error 
Case Else 

Err .Raise cmErrlnvalidLif eCycleState 

End Select 

Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
End Sub 



Business Logic: Operating on Groups of Business Objects 

Overview 

Sometimes, a BO 207 acts as a container for a group of other BOs. This happens 
when performing operations involving multiple BOs. For example, to close, an 
insurance claim ensures that it has no open supplements or tasks. There might be 
a method on the insurance claim BO - CanClose() - that evaluates the business 
rules restricting the closing of a claim and return true or false. Another situation 
might involve retrieving the open tasks for a claim. The claim can loop through 
its collection of tasks, asking each task if it is open and, if so, adding it to a 
temporary collection which is returned to the caller. 

Example 

1 Claim Business Object 

1 Error handling omitted for clarity 

Public Function CanCloseO As Boolean 

CanClose = HasOpenTasks ( ) And HasOpenSupplements ( ) 
End Function 

Public Function HasOpenTasks ( ) As Boolean 

' assume that I have open tasks 
HasOpenTasks = True 

" loop through all my tasks and exit if I find one that is 

open 

Dim task As CTask 

For Each task In m_colTasks 

If task. IsOpen( ) Then Exit Function 
Next task 

* I must not have any open tasks 
HasOpenTasks = False 
End Function 

Public Function HasOpenSupplements ( ) As Boolean 
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" assume that I have open supplements 
HasOpenSupplements = True 

' loop through all my supplements and exit if I find one 
that is open 
5 Dim supp As CSupplement 

For Each supp In m_col Supplements 

If supp. IsOpen( ) Then Exit Function 
Next supp 

HasOpenSupplements = False 
10 End Function 

Public Function GetOpenTasks ( ) As Collection 

Dim task As CTask 
Dim colOpenTasks As Collection 
15 For Each task In m_colTasks 

If task. IsOpenO Then colOpenTasks . Add task, task. Id 
Next task 

Set GetOpenTasks = colOpenTasks 
End Function 

20 

Business Object Structures 

Overview 

When a BO 207 is added or updated, it sends all of its attributes down to a server 
25 component 222 to write to the database. Instead of explicitly referring to each 
attribute in the parameter list of the functions on the CCA 208 and server 
component 222 , all the attributes are sent in a single variant array. This array is 
also known as a structure. 

Approach 

30 Each editable BO 207 has a method named AsStruct that takes the object's 
member variables and puts them in a variant array. The CCA 208 calls this 
method on a BO 207 before it sends the BO 207 down to the server component 
222 to be added or updated. The reason that this is necessary is that, although 
object references can be passed by value over the network, the objects themselves 

35 cannot. Only basic data types like Integer and String can be sent by value to a 
server component 222 . A VB enumeration is used to name the slots of the 
structure, so that the server component 222 can use a symbolic name to access 
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elements in the array instead of an index. Note that this is generally used only 
when performing adds or full updates on a business object 207. 

In a few cases, there is a reason to re-instantiate the BO 207 on the server side. 
5 The FromStruct method does exactly the opposite of the AsStruct method and 
initializes the BO 207 from a variant array. The size of the structure passed as a 
parameter to FromStruct is checked to increase the certainty that it is a valid 
structure. 

10 When a BO 207 contains a reference to another BO 207, the AsStruct method 

stores the primary key of the referenced BO 207. For example, the Task structure 
contains a Performerld, not the performer BO 207 that is referenced by the task. 
When the FromStruct method encounters the Performerld in the task structure, it 
instantiates a new performer BO and fills in the ID, leaving the rest of the 

15 performer BO empty. 



Example 



CTask Business 



Object 



* enumeration of all task < 
Public Enum TaskAttributes 

cmTaskld 

cmTaskName 



all task attributes 



20 



cmTaskDescription 



25 



End Enum 



all task attributes declarations here 



x all setter and getter functions here 



30 



Public Function AsStruct () As CTask 

On Error Goto ErrorHandler 



35 



* create and fill structure 

Dim vStruct (cmTaskNumOf Attributes - 1) As Variant 

vStruct (cmTaskld) = m_vld 

vStruct (cmTaskName) = m_sName 

vStruct (cmTaskPerf ormerld) = m_vPer former Id 



40 



vStruct (cmTaskDescription) = m_sDescription 
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AsStruct = vStruct 
Exit Function 
ErrorHandler : 

Err. Raise Err. Number 
5 End Function 

Public Sub FromStruct (vStruct As Variant) 

On Error Goto ErrorHandler 

10 A check size of vStruct 

If Ubound (vStruct) <> (cmTaskNumOf Attributes - 1) Then 
Err. Raise cmErrlnvalidParameters 

1 update my values from the structure 
15 m_vld = vStruct (cmTaskld) 

m_sName = vStruct ( cmTaskName ) 

m_vPerf ormer . Id = vStruct (cmTaskPerf ormerld) 

m_sDescription = vStruct (cmTaskDescription) 
20 Exit Sub 

ErrorHandler : 

Err. Raise Err. Number 
End Sub 

25 

Cloning Business Objects 

Overview 

Often a copy of a business object 207 is made. Cloning is a way to implement 
this kind of functionality by encapsulating the copying process in the BO 207 
30 itself. Controllers 206 that need to make tentative changes to a business object 
207 simply ask the original BO 207 for a clone and make changes to the clone. If 
the user decides to save the changes, the controller 206 ask the original BO to 
update itself from the changes made to the clone. 

Approach 

35 Each BO 207 has a Clone method to return a shallow copy of itself. A shallow 
copy is a copy that doesn't include copies of the other objects that the BO 207 
refers to, but only a copy of a reference to those objects. For example, to clone a 
task, it does not give the clone a brand new claim object; it gives the clone a new 
reference to the existing claim object. Collections are the only exception to this 
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rule - they are always copied completely since they contain references to other 
BOs. 



Each BO 207 also has an UpdateFromClone method to allow it "merge" a clone 
5 back in to itself by changing its attributes to match the changes made to the clone. 

Example 

x CTask Business Object 

Public Function Clone () As CTask 

On Error Goto ErrorHandler 

L0 

1 create clone object 
Dim tskClone As CTask 
Set tskClone = New CTask 



' fill clone with my data 
With tskClone 

. Id = m_vld 

. Name = m_sName 

. Perf ormerld = m_vPerf ormerld 

Set .Performer = m_prf Perf ormer 

.Description = m_sDescription 
End With 



25 Set Clone = tskClone 

Exit Function 

ErrorHandler: 

Err. Raise Err. Number 

End Function 



Public Sub UpdateFromClone (tskClone As CTask) 

On Error Goto ErrorHandler 



1 set my values equal to the clone's values 
35 With tskClone 

m_vld = . ID 
m_sName = .Name 
m_vPerf ormerld = .Perf ormerld 
Set m_prf Perf ormer = .Performer 
40 : 

m_sDescription = .Description 
End With 



Exit Sub 
45 ErrorHandler: 

Err. Raise Err. Number 
End Sub 
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Half-Baked Business Objects 

5 Overview 

BOs 207 occasionally are filled only half-full for performance reasons. This is 
done for queries involving multiple tables that return large data sets. Using half- 
baked BOs 207 can be an error prone process, so it is essential that the half- 
baking of BOs are carefully managed and contained. 

10 

In most applications, there are two kinds of windows - search windows and 
edit/detail windows. Search windows are the only windows that half-bake BOs 
207. Generally, half-baking only is a problem when a detail window expecting a 
fully-baked BO receives a half-baked BO from a search window. 

15 Approach 

Detail windows refresh the BOs 207 they are passed by the search windows, 
regardless of whether or not they were already fully-baked. This addresses the 
problems associated with passing half-baked BOs and also helps ensure that the 
BO 207 is up-to-date. 

20 

This approach requires another type of method (besides Get, Add, Update, and 
Delete) on the CCA 208: a Refresh method. This method is very similar to a Get 
method (in fact, it calls the same method on the server component) but is unique 
because it refreshes the data in objects that are already created. The detail 
25 window's controller 206 calls the appropriate CCA 208 passing the BO 207 to be 
refreshed, and may assume that, when control returns from the CCA 208, the BO 
207 will be up-to-date and fully-baked. 

This is may not be necessary if two windows are very closely related. If the first 
30 window is the only window that ever opens the second, it is necessary for the 



second window to refresh the BO 207 passed by the first window if it knows that 
the BO 207 is baked fully enough to be used. 



5 

CCAs 

CCAs 208 are responsible for transforming data from row and columns in a 
10 recordset to business objects 207, and for executing calls to server components 
222 on behalf of controllers 206. 

Retrieving Business Objects 

Overview 

15 After asking a component to retrieve data, the CCA 208 marshals the data 
returned by the component into business objects 207 that are used by the UI 
Controller 206. 

Approach 

The marshaling process is as follows: 

20 

CCAs 208 call GetRows on the recordset to get a copy of its data in a variant 
array in order to release the recordset as soon as possible. A method exist to 
coordinate the marshaling of each recordset returned by the component. 

25 Only one recordset is coordinated in the marshaling process of a single method. 
A method exist to build a BO from a single row of a recordset. This method is 
called once for each row in the recordset by the marshaling coordination method. 

Example 
30 1 Task CCA 

Public Function GetAllTasks ( ) As Collection 
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On Error Goto ErrorHandler 

" call a helper method to retrieve tasks 
Dim vRows As Variant 
5 vRows = RetrieveAllTasks 

Dim i As Integer 
Dim task As CTask 
Dim colTasks As Collection 
10 Set colTasks = New Collection 

1 vRows is dimmed as column, row. Loop til I run out of 
rows . 

For i = 0 To Ubound (vRows , 2) 
15 1 build BO using helper method 

Set task = BuildTaskFromRow (vRows , i) 
' add to collection with ID as the key 
colTasks. Add task, task. Id 

Next i 

20 

Set MarshalTasks = colTasks 
Exit Function 
ErrorHandler: 

Err. Raise Err. Number 
25 End Function 

Private Function RetrieveAllTasks ( ) As Variant 

On Error Goto ErrorHandler 

30 1 call my component and get a recordset full of all tasks 

Dim rs As ADOR . Recordset 
Set rs = tskComp.GetAllTasks ( ) 

1 get data in variant array from the recordset 
35 GetAllTasks = rs.GetRows 

* release the recordset ASAP 
rs .Close 

Set rs = Nothing 

40 

Exit Function 
ErrorHandler : 

Err. Raise Err. Number 
End Function 

45 

Private Function BuildTaskFromRow(vRows As Variant, 
nCurrentRow As Integer, _ 

Optional task As CTask) As 

CTask 

50 On Error Goto ErrorHandler 



create task if it wasn't passed 
If task Is Nothing Then Set task = New CTask 
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' fill task with data 
With task 

. Id = vRows ( 0 , nCurrentRow) 

.Name = vRowsd, nCurrentRow) 

. Per former Id = vRows(2, nCurrentRow) 

.Description = vRows(32, nCurrentRow) 
End With 

Set BuildTaskFromRow = task 

Exit Function 
ErrorHandler : 

Err. Raise Err. Number 
End Function 



Refreshing Business Objects 

Overview 

The logic to refresh BOs 207 is very similar to the logic to create them in the first 
place. A "refresh" method is very similar to a "get" method, but must use BOs 
207 that already exist when carrying out the marshalling process. 

Example 

* Task CCA 

Public Sub RefreshTask(task As CTask) 

On Error Goto ErrorHandler 

1 call a helper method to retrieve tasks 
Dim vRow As Variant 

vRow = RetrieveTaskWithId{task. Id) 

BuildTaskFromRow vRow, i, task 

Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
End Sub 

Private Function RetrieveTaskWithId(vId As Variant) As Variant 

On Error Goto ErrorHandler 

' call my component and get a recordset full of all tasks 

Dim rs As ADOR . Recordset 

Set rs = tskComp.GetTaskWithld(vId) 



45 



^ get data in variant array from the recordset 
RetrieveTaskWithld = rs.GetRows 



* release the recordset ASAP 
rs .Close 

Set rs = Nothing 



5 Exit Function 

ErrorHandler : 

Err. Raise Err. Number 
End Function 

10 

Adding Business Objects 

Overview 

Controllers 206 are responsible for creating and populating new BOs 207. To 
15 add a BO 207 to the database, the controller 206 must call the CCA 208, passing 
the business object 207 to be added. The CCA 208 calls the AsStruct method on 
the BO 207, and pass the BO structure down to the component to be saved. It 
then updates the BO 207 with the ID and timestamp generated by the server. 
Note the method on the CCA 208 just updates the BO 207. 

20 Example 

* Task CCA 

Public Sub AddTask(task As CTask) 

On Error Goto ErrorHandler 

25 v call component to add task passing a task structure 

Dim vldAndTimestamp As Variant 

vldAndTimestamp = tskComp . AddTask (task. AsStruct () ) 

* update ID and Timestamp on task 
30 task. Id = vldAndTimestamp { 0) 

task. TimeStamp = vldAndTimestamp (1) 

Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
35 End Sub 



Updating Business Objects 

Overview 

40 The update process is very similar to the add process. The only difference is that 
the server component only returns a timestamp, since the BO already has an ID. 



-52- 



Example 

s Task CCA 

Public Sub UpdateTask(task As CTask) 

On Error Goto ErrorHandler 

5 

1 call component to update task passing a task structure 
Dim iTimeStamp As Long 

lTimeStamp = tskComp.AddTask(task.AsStruct () ) 

10 ' update Timestamp on task 

task.TimeStamp = ITimeStamp 

Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
15 End Sub 

Deleting Business Objects 

Deleting Overview 

Like the add and the update methods, delete methods take a business object 207 
20 as a parameter and do not have a return value. The delete method does not 
modify the object 207 it is deleting since that object will soon be discarded. 

Example 

* Task CCA 

Public Sub DeleteTask(task As CTask) 

25 On Error Goto ErrorHandler 

* call component to update task passing a the ID and 
Timestamp 

tskComp.DeleteTask task. Id, task.TimeStamp 
30 Exit Sub 

ErrorHandler: 

Err. Raise Err. Number 
End Sub 



SERVER COMPONENT 



40 



Server components 222 have two purposes: enforcing business rules and 
carrying out data access operations. They are designed to avoid duplicating logic 
between functions. 
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Designing for Reuse 



Enforcing Encapsulation 

Each server component 222 encapsulates a single database table or a set of 
closely related database tables. As much as possible, server components 222 
5 select or modify data from a single table. A component occasionally selects from 
a table that is "owned" or encapsulated by another component in order to use a 
join (for efficiency reasons). A server component 222 often collaborates with 
other server components to complete a business transaction. 

Portioning Logic between Multiple Classes 
10 If the component becomes very large, it is split into more than one class. When 
this occurs, it is divided into two classes - one for business rules and one for data 
access. The business rules class implements the component's interface and 
utilizes the data access class to modify data as needed. 

15 Example 

Private Function MarkTasklnError (vMsg As Variant, _ 



20 



vTaskld As Variant, _ 
lTimestamp As Variant, _ 
sReason As String) As Long 



On Error GoTo ErrorHandler 

Const cmMethodName = "MarkTasklnError" 



25 



v set the SQL statement 

Dim sSQL As String 

sSQL = cmSQLMarkTasklnError 



30 



1 get a new times tamp 
Dim lNewTimeStamp As Long 
lNewTime Stamp = GetTimeStamp ( ) 



create and fill a collecti< 



of arguments to be 



:rged 



with 



35 



1 the SQL by the ExecuteQuery method 
Dim colArgs As CCollection 
Set colArgs = New CCollection 
With colArgs 



40 



.Add lNewTime Stamp 
.Add cmDBBooleanTrue 
.Add sReason 
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.Add vTaskld 
.Add ITimestamp 
End With 

5 1 run the SQL and set my return value 

ExecuteQuery vMsg, cmUpdate, sSQL, colArguments : =colArgs 
MarkTasklnError = lNewTimeStamp 

' tell MTS I'm done 
10 GetObjectContext .SetComplete 

Exit Function 

ErrorHandler : 

' do error handling here 
15 End Function 



20 



25 



30 

ERROR HANDLING 



General Information 



35 
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With the exception of "Class_Initialize", "Class_Terminate", and methods called 
within an error handler, every function or subroutine has a user defined 'On Error 
GoTo' statement. The first line in each procedure is: On Error GoTo 
ErrorHandler. A line near the end of the procedure is given a label 
5 "ErrorHandler". (Note that because line labels in VB 5.0 have procedure scope, 
each procedure can have a line labeled "ErrorHandler"). The ErrorHandler label 
is preceded by a Exit Sub or Exit Function statement to avoid executing the error 
handling code when there is no error. 

10 Errors are handled differently based on the module's level within the application 
(i.e., user interface modules are responsible for displaying error messages to the 
user). 

All modules take advantage of technical architecture to log messages. Client 
15 modules that already have a reference to the architecture call the Log Manager 
object directly. Because server modules do not usually have a reference to the 
architecture, they use the LogMessage() global function complied into each 
server component. 

20 Any errors that are raised within a server component 222 are handled by the 
calling UI controller 206. This ensures that the user is appropriately notified of 
the error and that business errors are not translated to unhandled fatal errors. 

All unexpected errors are handled by a general error handler function at the 
25 global Architecture module in order to always gracefully shut-down the 
application. 



Server Component Errors 
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The error handler for each service module contains a Case statement to check for 
all anticipated errors. If the error is not a recoverable error, the logic to handle it 
is first tell MTS about the error by calling GetObjectContext.SetAbort(). Next, 
the global LogMessage() function is called to log the short description intended 
5 for level one support personnel. Then the LogMessage() function is called a 
second time to log the detailed description of the error for upper level support 
personnel. Finally, the error is re-raised, so that the calling function will know 
the operation failed. 



10 A default Case condition is coded to handle any unexpected errors. This logs the 
VB generated error then raises it. A code sample is provided below: 



Following is an example of how error handling in the task component is 
implemented when an attempt is made to reassign a task to a performer that 
15 doesn't exist. Executing SQL to reassign a task to a non-existent performer 
generates a referential integrity violation error, which is trapped in this error 
handler: 

'Class Declarations 
20 Private Const cmClassName = "CTaskComp" 

Public Sub ReassignTask(...) 

On Error GoTo ErrorHandler 

Private Const cmMethodName = "ReassignTask" 
25 Private Const cmErrReassignTask = "Could not reassign 

task. " 

' logic to reassign a task 

30 GetObj ectContext . SetComplete 

Exit Sub 

ErrorHandler : 

Dim sShortDescr As String 
35 sShortDescr = cmErrReassignTask 

1 log short description as warning 

LogMessage vMsg, Err. Number, cmS ever i tyWarning , 

cmClassName, cmMethodName, sShortDescr 



40 



Dim sLongDescr As String 
Select Case Err. Number 
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Case cmErrRef IntegrityViolation 
GetObjectContext . SetAbort 

sLongDescr = "Referential integrity violation - 

tried " _ 

& "to reassign task to a non-existant 

performer. " _ 

& "Association ID: " & sAssnld _ 
& "Association Type: " & sAssnType _ 
& "Old Performer Id: " & sOldPerf ormerld _ 
& "New Performer Id: " & sNewPerf ormerld 
1 log long description as severe 
LogMessage vMsg, Err. Number, cmSeveritySevere , 
cmClassName, cmMethodName , _ 

sLongDescr 
Err. Raise Err. Number 

* more error handling 

Case Else 

* let architecture handle unanticipated error 
Dim nResumeCode As Integer 

nResumeCode = GeneralErrorHandler (vMsg, cmServer, 
cmClassName, cmMethodName) 

Select Case nResumeCode 
Case cmErrorResume 

Resume 
Case cmErrorResumeNext 

Resume Next 
Case cmErrorExit 

Exit Sub 
Case Else 

GetOb j ectContext . Abort 
Err . Rai se Err . Number 
End Select 
End Select 
End Sub 



CCAs, CCIs, Business Objects, and Forms 

40 All CCFs, CCA's, Business Objects, and Forms raise any error that is generated. 
A code sample is provided below: 

Sub SubName ( ) 

On Error GoTo ErrorHandler 
45 <the procedure's code here> 



Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
50 End Sub 
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5 User Interface Controller Errors 

The user interface controllers 206 handle any errors generated and passed up 
from the lower levels of the application. UI modules are responsible for handling 
whatever errors might be raised by server components 222 by displaying a 
message box to the user. 

10 

Any error generated in the UI's is also displayed to the user in a dialog box. Any 
error initiated on the client is logged using the LogMessage() procedure. Errors 
initiated on the server will already have been logged and therefore do not need to 
be logged again. 

15 

All unexpected errors are trapped by a general error method at the global 
architecture module. Depending on the value returned from this function, the 
controller may resume on the statement that triggered the error, resume on the 
next statement, call its Quiesce function to shut itself down, or call a Shutdown 
20 method on the application object to shutdown the entire application. 

No errors are raised from this level of the application, since controllers handle all 
errors. A code sample of a controller error handler is provided below: 

25 'Class Constants 

Private Const cmClassName As String = " <ComponentName> " 

Sub SubNameO 

On Error GoTo ErrorHandler 
30 Const cmMethodName As String = " <MethodName> " 

<the procedure's code here> 

35 : 

Exit Sub 
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ErrorHandler : 

Select Case CStr (Err .Number) 
5 Case ... 

'display the error to the user 

1 perform any necessary logic 

Exit Sub (or Resume, or Resume Next) 

10 : 

Case Else 

Dim nResumeCode As Integer 
nResumeCode = GeneralErrorHandler (vMsg, 
cmController , cmClassName, cmMethodName) 
15 Select Case CStr (nResumeCode) 

Case cmErrorResume 

Resume 
Case cmErrorResumeNext 
Resume Next 
20 Case cmErrorExit 

Exit Sub 
Case cmErrorQuiesce 

Quiesce 
Case Else 

25 ob j App . SHUTDOWN 

End Select 
End Select 
End Sub 

30 

LOCALIZATION 



The CBAM application is constructed so that it can be localized for different 
35 languages and countries with a minimum effort or conversion. 



Requirements and Scope 



The CBAM architecture provides support for certain localization features: 
40 Localizable Resource Repository; 
Flexible User Interface Design; 
Date Format Localization; and 

Exposure of Windows Operation System Localization Features. 



Localization Approach Checklist 



Localization Feature 


Supported via 

Architecture 

Service 


Supported via 

Architecture 

API's 


Best Practices and 
Assumptions 


Language Code 
(Locale Identifier) 


•/ 






Time Zones 








Date/Time 




✓ 




Name 








Telephone Numbers 








Functions to Avoid 








Weights and Measures 








Money 








Addresses/Address Hierarchies 








Menus, Icons, Labels/Identifiers 
on Windows 








Messages/ Dialogs 








String Functions, Sort Order and 
String Comparison 








Code Tables 








Drop-Down Lists 








Form & Correspondence 
Templates 








Online and Printed Documentation 








Database (DB2) 








3 rd Party Controls 








Miscellaneous 









5 



Localizable Literals Repository 

The CB AM application has an infrastructure to support multiple languages. The 
architecture acts as a centralized literals repository via its Codes Table Approach. 



The Codes Tables have localization in mind. Each row in the codes table 
contains an associated language identifier. Via the language identifier, any given 
code can support values of any language. 
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Flexible Interface 400 

Flexible user interface 400 and code makes customization easy. The Figure 4 
5 illustrates how different languages are repainted and recompiled. For example, 
both a English UI 404, and a French UI 406 are easily accommodated. This 
entails minimal effort because both UIs share the same core code base 402. 
Updates to the UIs are merely be a superficial change. 

10 Generic graphics are used and overcrowding is avoided to create a user interface 
which is easy to localize. 



15 Data Localization 

Language localization settings affect the way dates are displayed on UI's (user 
interfaces). The default system display format is different for different 
Language/Countries. For Example: 
20 English (United States) displays "mm/dd/yy" (e.g., "05/16/98") 

English (United Kingdom) displays "dd/mm/yy" (e.g., "16/05/98"). 

The present inventions UI's employ a number of third-party date controls 
including Sheridan Calendar Widgets (from Sheridan Software) which allow 
25 developers to set predefined input masks for dates (via the controls' Property 
Pages; the property in this case is "Mask"). 

Although the Mask property can be manipulated, the default setting is preferably 
accepted (the default setting for Mask is "0 - System Default"; it is set at design 
30 time). Accepting the default system settings eliminates the need to code for 

multiple locales (with some possible exceptions), does not interfere with intrinsic 
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Visual Basic functions such as DateAdd, and allows dates to be formatted as 
strings for use in SQL. 

The test program illustrated below shows how a date using the English (United 
5 Kingdom) default system date format is reformatted to a user-defined format (in 
this case, a string constant for use with DB2 SQL statements): 

Const cmDB2DateAndTime = "mm-dd-yyyy-h.mm. ss" 

10 Private Sub cmdConvToDB2_Click ( ) 

Dim sDB2Date As String 

sDB2Date = Format$ (SSDateCombol .Date, 

cmDB2DateAndTime) 
txtDB2String .Text = sDB2Date 
15 End Sub 

Leverage Windows Operation System 

The CBAM architecture exposes interface methods on the RegistryService object 
20 to access locale specific values which are set from the control panel. 

The architecture exposes an API from the RegistryService object which allows 
access to all of the information available in the control panel. Shown below is 
the signature of the API: 

25 

GetRegionallnfo (Info As Regionallnfo) As String 

Where Regionallnfo can be any of the values in the table below: 



CmLanguageld 


CmDTDateSeparator 


cmDayLongNameMonday 


cmMonthLongNameJan 


CmLanguageLocalized 


CmDTTimeSeparator 


cmDayLongNameTue s day 


crriMonthLongNameF eb 


CmLanguageEngl i sh 


CmDTShortDateFormat 


cmDay LongName Wedn e s day 


cmMonthLongNameMar 


CmLanguageAbbr 


CmLDTongDateFormat 


cmDayLongNameThursday 


cmMonthLongNameApr 


CmLanguageNat ive 


CmDTT imeFormat 


cmDayLongNameFriday 


cmMonthLongNameMay 


CmCountryld 


CntDTDateFormatOrdering 


cmDayLongNameSaturday 


crrtMonthLongNameJun 


CmCountryLocalized 


CmDTLongDateOrder i ng 


cirtDay LongName Sunday 


cinMonthLongNameJul 


CmCountryEngl i sh 


CmDTTimeFormatSpecif ier 


cirtDayAbbrNameMonday 


cmMonthLongNameAug 


CmCountryAbbr 


CmDTCenturyFormat Spec i f i er 


cirtDayAbbrNameTuesday 


cmMonthLongNameSep 


CmCountryNative 


CittDTTimeWithLeadingZeros 


cmDayAbbrNameWednesday 


cmMonthLongNameOc t 


CmLanguageDe f aul 1 1 d 


CntDTDayWi thLeading Zer o s 


cmDayAbbrNameThursday 


cmMonthLongNameNov 


CmCountryDefaultld 


CmDTMon thwi thLe adi ng Z e r o s 


cmDayAbbrNameFriday 


crriMonthLongNameDec 




CirtDTDesignatorAM 


cmDayAbbrName Saturday 


cmMonthAbbrWameJan 




CmDTDesignatorPM 


cmDayAbbrName Sunday 


cmMonthAbbrNameFeb 
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Get Regionallnfo Example: 



cmMonthAbbrNameMar 
cmMonthAbbrNaraeApr 
ciriMoiithAbbrNaiaeMay 
cmMonthAbbrNameJun 
cmMonthAbbrName Ju 1 
cmMonthAbbrNameAug 
cirMonthAbbrNameSep 
crriMonthAbbrNameOc t 
cmMonthAbbrNameNov 
cmMonthAbbrNameDe c 



Private Sub Coiranandl_Click ( ) 

MsgBox "This is the language id for English: 
GetRegionallnf o (cmLanguageld) 
End Sub 



1 o Logical Unit of Work 

The Logical Unit of Work (LUW) pattern enables separation of concern between 
UI Controllers 206 and business logic. 

Overview 

15 Normally, when a user opens a window, makes changes, and clicks OK or Save, 
a server component 222 is called to execute a transaction that will save the user's 
changes to the database. Because of this, it can be said that the window defines 
the boundary of the transaction, since the transaction is committed when the 
window closes. 

20 

The LUW pattern is useful when database transactions span windows. For 
example, a user begins editing data on one window and then, without saving, 
opens another window and begins editing data on that window, the save process 
involves multiple windows. Neither window controller 206 can manage the 
25 saving process, since data from both windows must be saved as an part of an 
indivisible unit of work. Instead, a LUW object is introduced to manage the 
saving process. 



-64- 



The LUW acts as a sort of "shopping bag". When a controller 206 modifies a 
business object 207, it puts it in the bag to be paid for (saved) later. It might give 
the bag to another controller 206 to finish the shopping (modify more objects), 
5 and then to a third controller who pays (asks the LUW to initiate the save). 

Approach 

Controllers 206 may have different levels of LUW "awareness": 
Requires New : always creates a new LUW; 
10 Requires : requires an LUW, and creates a new LUW only if one is not passed by 
the calling controller; 

Requires Existing : requires an LUW, but does not create a new LUW if one is not 
passed by the calling controller. Raises an error if no LUW is passed; and 
Not Supported : is not capable of using an LUW. 

15 

Controllers 206 that always require a new LUW create that LUW in their 
ArchlnitClass function during initialization. They may choose whether or not to 
involve other windows in their LUW. If it is desirable for another window to be 
involved in an existing LUW, the controller 206 that owns the LUW passes a 
20 reference to that LUW when it calls the App Object 202 to open the second 
window. Controllers 206 that require an LUW or require an existing LUW 
accept the LUW as a parameter in the ArchlnitClass function. 

LUWs contain all the necessary logic to persist their "contents" - the modified 
25 BOs 207. They handle calling methods on the CCA 208 and updating the BOs 
207 with new IDs and/or timestamps. 



ARCHITECTURE API HIERARCHY 



30 
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Following is an overview of the architecture object model, including a 
description of each method and the parameters it accepts. Additional sections 
address the concepts behind specific areas (code caching, message logging, and 
data access) in more detail. 

5 

Arch Object 

Figure 5 depicts the current properties on the Arch Object 200. 

The following are APIs located on the Arch Object 200 which return either a 
10 retrieved or created instance of an object which implements the following 

interfaces: 

CodesManO 500; 

TextMan() 502; 

IdMan() 504; 
15 RegManO 506; 

LogManO 508; 

ErrManO 510; 

UserManO 512; and 

SecurityMan() 514. 

20 

AsMsgStructQ 

This method on the Arch Object returns a variant structure to pass along a remote 
message. 

25 

Syntax: 

Public Function AsMsgStruct ( ) As Variant 
End Function 

30 Example: 

Dim vMsg As Variant 

vMsg = obj Arch. AsMsgStruct 
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CodesMan 

The following are APIs located on the interface of the Arch Object 200 named 
CodesMan 500: 

CheckCacheFreshness() ; 

FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], 

[col AssignedCodes] ) ; 

FilterCodes(colAllCodes, nCodeStatus); 

GetCategoryCodes(nCategory) ; 

GetCodeObject(nCategory, sCode); 

GetResourceString(lStringld); 

GetServerDate(); 

RefreshCache(); 

Remove ValidDates(sCode, colPassedlnAssignedCodes); and 
SetServerDate(dtServerDate). 

CheckCacheFreshnessQ 

Checks whether the cache has expired, if so refresh. 
Syntax: 

Private Sub CheckCacheFreshness ( ) 
End Sub 

Example: 

CheckCacheFreshness 

FillControlQ 

This API is used to fill listboxes or comboboxes with values from a list of 
CodeDecodes. Returns a collection for subsequent lookups to Code objects used 
to fill controls. 
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Syntax: 

Public Function FillControl (ctlControl As Object, nCategory As CodeDecodeCats, 
nFillType As CodeDecodeLengths, Optional nCodeStatus As CodeDecodeFilters = 
cmValidCodes, Optional colAssignedCodes As CCollection) As CCollection 



10 

Parameters: 

ctlControl: A reference to a passed in listbox or combobox. 

nCategory: The integer based constant which classified these CodeDecodes from 
others. Several of the valid constants include: 
15 cmCatTaskType = 1 

cmCatSource 
cmCatTaskStatus 

nFillType: The attribute of the CodeDecode which you want to fill. Several of 
the valid values include: 
20 cmCode 

cmShortDecode 
cmLongDecode 

nCodeStatus: Optional value which filters the Code Decodes according to their 
Effective and Expiration dates. Several of the valid constants include: 
25 cmAllCodes Pending + Valid + Expired Codes 

cmPendingCodes Codes whose effective date is greater than the 

current date 
cmValidCodes Not Pending or Expired Codes 

colAssignedCodes: Used when filling a control which should fill and include 
30 assigned values. 

Example: 

'Declare an instance variable for States collection on object 
Private colstates As CCollection 

35 

-Call FillControll API, and set local collection inst var to collection of 
codes which were used to fill the control 1 . This collection will be used for 
subsequent lookups. 

Set colstates = objArch. CodesMan. FillControl ( frmCurrentForm. cboStates , 
40 cmCatStates, cmLongDecode) 

FilterCodesO 

Returns a collection of code/decodes that are filtered using their effective and 
expiration dates based on which nCodeStatus is passed from the fillcontrol 
method. 



45 



Syntax: 



Private Function FilterCodes (colAllCodes As CCollection, nCodeStatus As 
CodeDecodeFilters) As CCollection 
End Function 



colAllCodes : 
nCodeStatus : 

10 Example: 

Set colFilteredCodes = FilterCodes (colCodes , nCodeStatus) 

GetCategoryCodesQ 

Returns a collection of CCode objects given a valid category 



15 Syntax: 



Public Function GetCategoryCodes (nCategory As CodeDecodeCats) As CCollect: 
End Function 



nCategory: The integer based constant which classified these CodeDecodes fr< 

Example: 

Dim colMyStates As CCollection 

Set colMyStates = objArch. CodesMan. GetCategoryCodes (cmCatStates) 

'Below shows an example of looking up the Code value for the 
selected state. 
With frmCurrentForra.cboStates 
If .Listlndex > -1 Then 
Dim objCode As CCode 

Set objCode = colStates (. ItemData (. Listlndex) ) 

sStateCode = objCode. Code 
End If 
End With 

GetCodeObjectQ 

Returns a valid CCode object given a specific category and code. 



Syntax: 



Public Function GetCodeObject (nCategory As CodeDecodeCats, sCode As String) As 
CCode 

End Function 
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Parameters: 

nCategory: The integer based constant which classified these CodeDecodes from 
5 sCode: A string indicating the Code attribute of the CodeDecode object. 

Example: 

frmCurrentForm. lblState = objArch.CodesMan.GetCodeObject (cmCatStates, 
*IL") . LongDecode 

10 GetResourceStringO 

Returns a string from the resource file given a specific string ID. 

Syntax: 

Private Function GetResourceString ( IStringId As Long) As String 
15 End Function 

Parameters: 

IStringId: The id associated with the string in the resource file. 

20 Example: 

sMsg = arch. CodesMan. GetResourceString (CLng (vMes sage) ) 

GetServerDateQ 

Returns the date from the server. 

25 Syntax: 

Private Function GetServerDate ( ) As Date 
End Function 

Example: 

30 SetServerDate CCA. GetServerDate 

RefreshCacheQ 

Refreshes all of the code obhjects in the cache. 

Syntax: 

35 Private Sub Ref reshCache ( ) 

End Sub 
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Example: 

m_Cache . Ref reshCache 

Remove ValidCodes ( ) 

Removes all valid codes from the passed in assigned codes collection, which is 
5 used to see which codes are assigned and not valid. 

Syntax: 

Private Sub RemoveValidCod.es ( sCode As String, colPassedlnAssignedCodes As 
CCollection) 
10 End Sub 

Parameters: 

sCode: Name of code 

colPassedlnAssignedCodes: Codes already in use. 

15 

Example: 

RemoveValidCodes codCode . Code, colPassedlnAssignedCodes 

SetServerDateQ 

Sets the server date. 

20 

Syntax: 

Private Sub SetServerDate (dtServerDate As Date) 
End Sub 

25 Parameters: 

dtServerDate: Date of Server. 

Example: 

SetServerDate CCA. GetServerDate 

30 

TextMan 

The following are APIs located on the interface of the Arch Object 200 named 
35 TextMan 502. 
PairUpApostsO; 
PairUpAmps(); and 
MergeParms (). 
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PairllpAposts () 

Pairs up apostrophes in the passed string. 
Syntax: 

5 Public Function PairUpAposts ( sOriginalString As String) As String 

End Function 

Parameters: 

sOriginalString: string passed in by the caller 

10 

Example: 

Dim sString As String 

sString = objArch.TextMan. PairUpAposts ( "This is Monika's string") 
'expected return: sString = "This is Monika''s string" 

15 PairUpAmps () 

Pairs up ampersands in the passed string. 

Syntax: 

Public Function PairUpAmps ( sOriginalString As String) As String 
20 End Function 

Parameters: 

sOriginalString: string passed in by the caller 

25 Example: 

Dim sString As String 

sString = obj Arch. TextMan. PairUpAmps ( "Forms&Corr" ) 
'expected return: sString = "Forms&&Corr " 

30 MergeParms () 

Merges string with the passed parameters collection. 

Syntax: 

Public Function MergeParms (sString As String, colParms As CCollection) As 
35 String 
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OriginalString: string passed in by the caller 
olParms As Ccollection : collection of the parameters 



5 Example: 

Dim sString As String 

sString = objArch.TextMan.MergeParms (sString, colParms) 



10 IdMan 

The following are APIs located on the interface of the Arch Object 200 named 
IdMan 504: 
GetGUID(); 
15 GetSequenceUX); 
GetTimeStampO; 
GetTrackingNbr(); and 
GetUniqueId(). 

GetGUID () 

20 

Syntax: 

Public Function GetGUID () 
End Function 

25 Example: 

Dim vNewGuid As Variant 
vNewGuid = obj Arch. IdMan. GetGUID 

GetSequenceld () 

30 Syntax: 

Public Function GetSequenceld ( sTemplateType As CounterName ) As String 
End Function 



Parameters: 

35 sTemplateType: The string specifying the template requesting a sequence id 

(i.e. cmCountFC = Forms & Corr) 



Example: 

f rmCurrentForm. txtTemplateNumber = obj Arch . IdMan . GetSequenceld (cmCountFC) 
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GetTimeStamp () 

Syntax: 

Public Function GetTimeStamp ( ) 
5 End Function 

Example: 

Dim nNewTimeStamp As Long 

nNewTimeStamp = obj Arch. IdMan. GetTimeStamp 

10 



GetTrackingNbr () 

15 

Syntax: 

Public Function GetTrackingNbr ( ) 
End Function 

20 Example: 

Set objTechArch = New CTechArch 

sUniqueTrackNum = objTechArch. IdMan. GetTrackingNbr 

GetUniqueld () 

25 Syntax: 

Public Function GetUniqueld ( ) 
End Function 

Example: 

30 Dim vUid As Variant 

vNewUid = objArch. IdMan. GetUniqueld 



35 RegMan 

The following are APIs located on the interface of the Arch Object 200 named 
RegMan 506: 
GetCacheLife(); 
40 GetClientDSNQ; 
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GetComputerName() ; 

GetDefaultAndValidate(); 

GetFC Archi veDirectory() ; 

GetFCDistributionDirectoryO; 
5 GetFCMasterDirectoryO; 

GetFCUserDirector y() ; 

GetFC WorkingDirectoryO ; 

GetHelpPath(); 

GetLocalInfo(); 
10 GetLogLevel(); 

GetRegionalInfo(); 

GetRegValue(); 

GetServerDSN(); 

GetSettingO; 
15 GetTimerLogLevel(); 

GetTimerLogPath(); and 

GetUseLocalCodes(). 

GetCacheLifeQ 

20 Syntax: 

Public Function GetCacheLif e ( ) As String 
End Function 

Example: 

25 Dim s As String 

s = objArch.RegMan.GetCacheLife 

GetClientDSNQ 

Syntax: 

30 Public Function GetClientDSN ( ) As String 

End Function 

Example: 

Dim s As String 
35 s = objArch.RegMan. GetClientDSN 
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GetComputerNameQ 

Syntax: 

Public Function GetComputerName ( ) As String 
5 End Function 

Example: 

Dim s As String 

s = obj Arch. RegMan. GetComputerName 

10 GetDefaultAndValidateQ 

Syntax: 

Private Function GetDef aultAndValidate (sKey As String) As String 
End Function 

15 

Parameters: 

sKey: The key within the registry of which the user is requesting (i.e.: Help 
Path) 

20 Example: 



Dim sDefault As String 

sDefault = objArch. RegMan. GetDef aultAndValidate (sKey) 



GetFCArchiveDirectoryQ 



25 Syntax: 

Public Function GetFCArchiveDirectory ( ) As String 
End Function 

Example: 

30 Dim s As String 

s = objArch. RegMan. GetFCArchiveDirectory 

GetFCDistributionDirectoryQ 



Syntax: 



35 Public Function GetFCDistributionDirectory ( ) As String 

End Function 



Example: 



Dim s As String 
40 s = objArch. RegMan. GetFCDistributionDirectory 
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GetFCMasterDirectoryO 

Syntax: 

Public Function GetFCMasterDirectory ( ) As String 
5 End Function 

10 Example: 

Dim s As String 

s = obj Arch. RegMan. GetFCMasterDirectory 

GetFCUserDirectoryQ 

15 Syntax: 

Public Function GetFCUserDirectory ( ) As String 
End Function 

Example: 

20 Dim s As String 

s = obj Arch. RegMan. GetFCUserDirectory 

GetFCWorkingDirectoryO 

Syntax: 

25 Public Function GetFCWorkingDirectoryO As String 

End Function 

Example: 

Dim s As String 
30 s = obj Arch. RegMan. GetFCWorkingDirectory 

GetHelpPathQ 

Syntax: 

Public Function GetHelpPathf) As String 
35 End Function 

Example: 

Dim s As String 

s = obj Arch. RegMan. GetHelpPath 
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GetLocallnfoQ 

Syntax: 

5 Public Function GetLocallnf o ( ) As String 

End Function 

Example: 

Dim s As String 
10 s = objArch.RegMan.GetLocallnfo 

GetLogLevel() 

Syntax: 

Public Function GetLogLevel { ) As String 
15 End Function 

Example: 

Dim s As String 

s = objArch.RegMan.GetLogLevel 

20 GetRegionallnfoQ 

Allows access to all locale specific values which are set from control panel. 

Syntax: 

Public Function GetRegionallnf o (Inf o As Regionallnf o) As String 
25 End Function 

Parameters: 

Info: string containing the regional information. Several of the valid 

30 • cmLanguageld = &H1 ' language id 

» cmLanguageLocalized = &H2 ' localized name of language 

• cmLanguageEnglish = &H1001 ' English name of language 

• cmLanguageAbbr = &H3 ' abbreviated language name 

• cmLanguageNative = &H4 ' native name of language 



Example: 



Dim s As String 

s = objArch. RegMan. GetRegionallnf o 
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GetRegValueQ 

5 Syntax: 

Public Function GetRegValue ( ) As String 
End Function 

Example: 

10 Dim s As String 

s = obj Arch. RegMan. GetRegValue 

GetServerDSNQ 

Syntax: 

15 Public Function GetServerDSN ( ) As String 

End Function 

Example: 

Dim s As String 
20 s = obj Arch. RegMan. GetServerDSN 

GetSettingO 

Get setting from the registry. 
Syntax: 

25 Public Function GetSetting(sKey As String) As String 

End Function 

Parameters: 

sKey: The key within the registry of which the user is requesting (i 
30 Help Path) 

Parameters: 

GetHelpPath = GetSetting ( cmRegHelpPathKey) 

GetTimerLogLevelQ 

35 

Syntax: 

Public Function GetTimerLogLevel ( ) As String 
End Function 
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Example: 

Dim s As String 

s = objArch. RegMan. GetTimerLogLevel 

5 GetTimerLogPathQ 

Syntax: 

Public Function GetTimerLogPath ( ) As String 
End Function 



Example. 



-- obj Arch. RegMan. GetTimerLogPath 



GetUseLocalCodesQ 

15 Syntax: 



Public Function GetUseLocalCodes ( ) As String 
End Function 



Example: 



Dim s As String 

s = obj Arch. RegMan. GetUseLocalCodes 



LPSTRToVBStringQ 

Extracts a VB string from a buffer containing a null terminated string. 



25 Syntax: 



Private Function LPSTRToVBStringS (ByVal s$) 
End Function 



LogMan 

The following are APIs located on the interface of the Arch Object 200 named 
LogMan 508: 
35 LogMessage (); 

WriteToDatabaseO; and 
WriteToLocalLogO- 
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LogMessage () 

Used to log the message. This function will determine where the message 
should be logged, if at all, based on its severity and the vMsg's 
log level. 

5 

Syntax: 

Public Sub LogMessage (vMsg As Variant, _ 

1 Severity As Long, _ 
sClassName As String, _ 
10 sMethodName As String, _ 

sVersion As String, _ 
lErrorNum As Long, _ 

Optional sText As String = vbNullString) 

End Sub 

15 

Parameters: 

vMsg: the standard architecture message 
lSeverity: the severity of the message 
sClassName: the name of the class logging the message 
20 sMethodName: the name of the method logging the message 

sVersion: the version of the binary file (EXE or DLL) that contains the method 
logging message 

lErrorNum: the number of the current error 

sText : an optional parameter containing the text of the message. If omitted, 
25 the text will be looked up in a string file or the generic VB error 

description will be used 

Example: 

If Err. Number <> 0 Then 
30 v log message 

Arch. LogMan. LogMessage (vMsg, cmSeverityFatal , "COrganizationCTLR" , 

GetVersion ( ) , Err . Number , Err .Description) 

35 Err. Raise Err. Number 

End If 

WriteToDatabase () 

Used to log the message to the database on the server using the CLoggingComp. 
40 This function returns the Trackingld that is generated by the CLoggingObject. 

Syntax: 

Private Sub WriteToDatabase (vMsg As Variant, msgToLog As CMessage) 
End Sub 

45 



Parameters: 



vMsg: the standard architecture message 

msgToLog: a parameter containing the text of the message. 



Example: 



If msgToLog. I sLoggableAtLevel (m_lLocalLogLevel) Then 
WriteToDatabase vMsg, msgToLog 



WriteToLocalLog () 

10 Used to log the message to either a flat file, in the case of Windows 95, or the NT 
Event Log, in the case of Windows NT. 

Syntax: 

Private Sub WriteToLocalLog (msgToLog As CMessage) 
15 End Sub 

Parameters: 

msgToLog: a parameter containing the text of the message. 



20 Example: 



ErrorHandler : 

WriteToLocalLog msgToLog 
End Sub 



ErrMan 

The following are APIs located on the interface of the Arch Object 200 named 
30 ErrMan 510: 
HandleError(); 
RaiseOriginal(); 
ResetError(); and 
Update(). 

35 HandleErrorQ 

This method is passed through to the general error handler in MArch.bas 



Syntax: 



Public Function HandleError (vMsg As Variant, nCompType As CompType, sClassName 
As String, sMethodName As String) As ErrResumeCodes 
End Sub 
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Parameters: 

vMsg: General Architecture Information 

nCompType : Contains tier information (Client or Server) 
5 sClassName: Class which raised the error. 

sMethodName: Method which raised the error. 



RaiseOriginalQ 

This method is used to Reset the error object and raise. 

10 

Syntax: 

Public Sub RaiseOriginal ( ) 
End Sub 

15 Example: 

ob j Arch. ErrMan .RaiseOriginal 

ResetErrorQ 

This method is used to reset attributes. 
20 Syntax: 

Public Sub ResetErrorO 
End Sub 

Example: 

25 obj Arch. ErrMan. ResetError 



30 UpdateQ 

This method is used to update attributes to the values of VBs global Error object. 
Syntax: 

Public Sub Update () 
35 End Sub 

Example: 

obj Arch . ErrMan . Update 

40 



UserMan 



The following are APIs located on the interface of the Arch Object 200 named 
5 UserMan 512. 

Userld; 

Employeeld; 

EmployeeName; 

EmployeeFirstName; 
10 EmployeeLastName; 

EmployeeMiddlelnitial ; 

GetAuthorizedEmployees; 

IsSuperOf (); 

IsRelativeOf(); and 
15 IsInRole(). 

Userld() 

Syntax: 

Public Property Get userld () As String 
20 End Property 

Example: 

Dim SNewUserld As String 
sNewUserld = objArch. UserMan. Userld 

25 EmployeeId() 

Syntax: 

Public Property Get Employeeld () As String 
End Property 

30 

Example: 

Dim sNewEmployeeld As String 
sNewEmployeeld = objArch. UserMan. Employeeld 



EmployeeNameQ 



5 Syntax: 

Public Property Get EmployeeName ( ) As String 
End Property 

Example: 

10 Dim sName As String 

sName = obj Arch. UserMan. EmployeeName 

EmployeeFirstNameQ 

Syntax: 

15 Public Property Get EmployeeFirstName ( ) As String 

End Property 

Example: 

Dim sFName As String 
20 sFName = obj Arch. UserMan . EmployeeFirstName 

Employ eeLasiNameQ 

Syntax: 

Public Property Get EmployeeLastName 0 As String 
25 End Property 

Example: 

Dim sLName As String 

sLName = obj Arch. UserMan . EmployeeLastName 

30 EmployeeMiddlelnitialQ 

Syntax: 

Public Property Get EmployeeMiddlelnitial ( ) As String 
End Property 

35 

Example: 

Dim sMI As String 

sMI = obj Arch. UserMan. EmployeeMiddlelnitial 



GetAuthorizedEmployeesQ 

Creates a collection of user's supervisees from the dictionary and returns 
GetAuthorizedEmployees - collection of authorized employees 



5 Syntax: 

Public Function GetAuthorizedEmployees ( ) As CCollection 
End Function 

Example: 

10 Dim colAuth As Collection 

colAuth = objArch.UserMan. GetAuthorizedEmployees 

IsSuperOf () 

Checks if the current user is supervisor of the passed in user. 

15 

Syntax: 

Public Function IsSuperOf ( sEmpId As String) As Boolean 
End Function 

20 Parameters: 

sEmpId: string containing Employee ID number 

Example: 

Dim blsSuperOfMonika As Boolean 
25 blsSuperOfMonika = objArch.UserMan . IsSuperOf { "TS012345" ) 

IsRelativeOf () 

Checks if the passed in user is relative of the current user. 
Syntax: 

30 Public Function IsRelativeOf (sEmpId As String) As Boolean 

End Function 

Parameters: 

sEmpId: string containing Employee ID number 

35 

Example: 

Dim blsRelativeOfMonika As Boolean 

blsRelativeOfMonika = obj Arch .UserMan. IsRelativeOf ( "TS012345" ) 



IsInRole () 

Checks to see if the current user is in a certain role. 



Syntax: 

Public Function IsInRole (sRole As String) As Boolean 
End Function 

10 Parameters: 

sRole: string containing role 

Example: 

Dim blsInRoleTaskLibrarian As Boolean 
15 blsInRoleTaskLibrarian = obj Arch. . UserMan . IsInRole ( "TA" ) 



20 SecurityMan 

The following APIs are located on the interface of the Arch Object 200 named 
SecurityMan 514. 

25 EvalClaimRules; 

EvalFileNoteRules; 

EvalFormsCorrRules; 

EvalOrgRules; 

EvalRun ApplicationRules ; 
30 EvalRunEventProcRules; 

EvalTaskTemplateRules ; 

EvalUserProfilesRules; 

IsOperAuthorized; 

GetUserld; and 
35 OverrideUser. 
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EvalClaimRules () 

This API references business rules for Claim security checking and returns a 
boolean if rules are met. 

5 Syntax: 

Private Function EvalClaimRules (IBasicOp As cmBasicOperations, vContextData As 
Variant) As Boolean 
End Function 

10 Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. 
Delete) 

vContextData: a variant array holding relevant business objects or other 

15 

Example: 

Select Case lOperation 
Case cmWorkOnClaim 

20 IsOperAuthorized = EvalClaimRules (cmView, vContextData) And _ 

EvalClaimRules (cmEdit, vContextData) 

EvalFileNoteRules () 

This API references business rules for FileNote security checking and returns a 
boolean if rules are met. 

25 

Syntax: 

Private Function EvalFileNoteRules ( IBasicOp As cmBasicOperations, vContextData 
As Variant) As Boolean 
End Function 

30 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. 
Delete) 

vContextData: a variant array holding relevant business objects or other 
35 information. 

Example: 

Select Case lOperation 
40 Case cmDeleteFileNote 

IsOperAuthorized = EvalFileNoteRules (cmDelete, vContextData) 



5 



EvalFormsCorrRules () 

This API references business rules for Forms and Corr security checking and 
returns a boolean if rules are met. 



Syntax: 



Private Function EvalFormsCorrRules ( IBasicOp As cmBasicOperations) As Boolean 
End Function 



IBasicOp: 
Delete) 



Example: 



Select Case lOperation 

Case cmMaintainFormsCorr 

IsOperAuthorized = EvalFormsCorrRules (cmEdit) And _ 
EvalFormsCorrRules (cmDelete) And _ 
EvalFormsCorrRules (cmAdd) 



EvalOrgRules () 

This API references business rules for Event Processor security checking and 
returns a boolean if rules are met. 

25 Syntax: 

Private Function EvalOrgRules (IBasicOp As cmBasicOperations) As Boolean 
End Function 



Parameters: 

30 IBasicOp: a basic operation the current user is wishing to perform (i.e. 

Delete) 



Example: 



Select Case lOperation 

Case cmMaintainOrg 

IsOperAuthorized = EvalOrgRules (cmAdd) And _ 
EvalOrgRules (cmEdit) And _ 
EvalOrgRules (cmDelete) 



5 



EvalRunApplicationRules () 

This API references business rules for running the application and returns a 
boolean if rules are met. 



Syntax: 



Private Function EvalRunApplicationRules (IBasicOp As cmBasicOperations) As 
End Function 



IBasicOp: a basic operation the current user is wishing to perform (i.e. 
Delete) 

Example: 

Select Case lOperation 

Case cmRunApplication 

IsOperAuthorized = EvalRunApplicationRules (cmExecute) 

EvalRunEventProcRules () 

This API references business rules for Event Processor security checking and 
returns a boolean if rules are met. 



25 Syntax: 



Private Function EvalRunEventProcRules { IBasicOp As cmBasicOperations) As 

Boolean 

End Function 



30 Parameters: 



IBasicOp: a basic operation the current user is wishing to perform (i 
Delete) 



35 Example: 

Select Case lOperation 
Case cmRunEventProcessor 

IsOperAuthorized = EvalRunEventProcRules (cmExecute) 
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EvalTaskTemplateRules () 

This API references business rules for Task Template security checking and 
5 returns a boolean if rules are met. 

Syntax: 

Private Function EvalTaskTemplateRules ( IBasicOp As cntBasicOperations) As 
Boolean 
10 End Function 



IBasicOp: a basic operation the current user is wishing to perform (i.e. 
Delete) 

15 

Example: 

Select Case lOperation 

Case cmMaintainTaskLibrary 
20 I sOper Authorized = EvalTaskTemplateRules (cmAdd) And _ 

EvalTaskTemplateRules (cmEdit) And _ 
EvalTaskTemplateRules (cmDelete) 

EvalUserProfileRules () 

This API references business rules for Task Template security checking and 
25 returns a boolean if rules are met. 



Syntax: 



Private Function EvalUserProfileRules (IBasicOp As cntBasicOperations, 
vContextData As Variant) As Boolean 
30 End Function 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. 
Delete) 

35 vContextData: a variant array holding relevant business objects or other 

information. 



Example: 



Select Case lOperation 
Case cmlsRelativeOf 

IsOperAuthorized = EvalUserProf ileRules (cmView, vContextData) And 



EvalUserProf ileRules (cmAdd, vContextData) And _ 
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EvalUserProfileRules (cmEdit, vContextData) And 
EvalUserProfileRules (cirtDelete, vContextData) 



GetUserld () 

Returns the login name/user id of the current user. 
Syntax: 

Public Function GetUserld () As String 
End Function 

Example: 

Dim sUserld as String 
sUserld = GetUserld 

IsOper Authorized () 

This API references business rules and returns a boolean determining whether the 
user has security privileges to perform a certain operation. 

Syntax: 

Public Function IsOperAuthorized (vMsg, as variant, nOperation as cmOperations, 
vContext As Variant) As Boolean 
End Function 



vMsg: the standard architecture message 

nOperation: an enumeration containing name of operation to be checked. 
vContext: a variant array holding relevant business objects or other 
information. 



Example: 



Dim bCanlDoThis As Boolean 

bCanlDoThis = obj Arch. SecurityMan. IsOperAuthorized (vMsg, aOperationName, 
vContext) 

TlbEditlcon. Enabled = bCanlDoThis 



OverrideUser () 

Re-initializes for a different user. 

40 

Syntax: 

Public Sub OverrideUser (Optional sUserld As String, Optional dictRoles As 
CDictionary, Optional dictSubs As CDictionary) 
End Function 
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Parameters: 

sUserld: 
dictRoles: 
5 dictSubs: 



Example: 

Dim x As New CTechArch 
10 x. SecurityMan.OverrideUser "Everyone", New CDictionary, New CDictionary 



15 

CODES FRAMEWORK 
General Requirements 

20 Separate tables (CodesDecodes) are Created for storing the static values. 

Only the references to codes/decodes are stored in business tables (e.g., Task) 
which utilize these values. This minimizes the size of the business tables, since 
storing a Code value takes much less storage space than its corresponding 
25 Decode value (e.g., For State, "AL" is stored in each table row instead of the 
string "Alabama"). 

CodeDecodes are stored locally on the client workstation in a local DBMS. On 
Application startup, a procedure to ensure the local tables are in sync with the 
30 central DBMS is performed. 
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Infrastructure Approach 

The present invention's Code Decode Infrastructure 600 Approach outlines the 
method of physically modeling codes tables. The model allows codes to be 
5 extended with no impact to the physical data model and/or application and 

architecture. Figure 6 shows the physical layout of CodeDecode tables according 
to one embodiment of the present invention. 

Infrastructure 

10 The physical model of the CodeDecode infrastructure 600 does the following: 
Supports relational functionality between CodeDecode objects; 
Supports extensibility without modification to the DBMS or Application 
Architecture; 

15 Provides a consistent approach for accessing all CodeDecode elements; and 
Is easily maintainable. 

These generic tables are able to handle new categories, and modification of 
20 relationships without a need to change the DBMS or CodeDecode Application 
Architecture. 

Benefits of this model are extensibility and maintainability. This model allows 
for the modifications of code categories without any impact to the DBMS or the 
25 Application Architecture code. This model also requires fewer tables to 

maintain. In addition, only one method is necessary to access CodeDecodes. 

Table Relationships and Field Descriptions: 

(pk) indicates a Primary Key 

30 



Code_Category 602 
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• C_Category (pk): The category number for a group of codes 

• C_Cache (currently not utilized): Can indicate whether the category 

should be cached in memory on the client machine 

• T_Category: A text description of the category (e.g., Application Task 
Types, Claim Status, Days of Week) 

• D_Last_Update: The date any data within the given category was last 

updated; this field is used in determining whether to update a category or 
categories on the local data base 
Relationships 

• A one-to-many relationship with the table Code (i.e., one category can 
have multiple codes) 

Code 604 

• C_Category (pk): The category number for a group of codes 

• C_Code (pk): A brief code identifier (up to ten characters; the current 
maximum length being used is five characters) 

• D_Effective: A date field indicating the code's effective date 

• D_Expiration: A date field indicating the code's expiration date (the 

default is January 1, 2999) 
Relationships 

• A many-to-one relationship with Code_Category 602 (described above) 

• A one-to-many relationship with Code_Relations 606 (a given category- 
and-code combination can be related to multiple other category-and-code 
combinations) 

Code_Relations 606 

• C_Categoryl (pk): The first category 

• C_Codel (pk): The first code 

• C_Category2 (pk): The related category 



-95- 



• C_Code2 (pk): The related code 
Relationships 

• A many-to-one relationship with the Code table (each category and code 
in the Code table can have multiple related category-code combinations) 



Code_Decode 608 

• C_Category (pk): The category number for a group of codes 

• C_Code (pk): A brief code identifier (up to ten characters; the current 
maximum length being used is five characters) 

• N_Lang_ED (pk): A value indicating the local language setting (as defined 

in a given machine's Regional Settings). For example, the value for 
English (United States) is stored as 0409. Use of this setting allows for 
the storage and selection of text code descriptions based on the language 
chosen 

• T_Short_Desc: An abbreviated textual description of C_Code 

• T_Long_Desc: A full-length textual description of C_Code — what the 

user will actually see (e.g., Close Supplement - Recovery, File Note, 
Workers Compensation) 



Localization Support Approach 



25 Enabling Localization 

Codes have support for multiple languages. The key to this feature is storing a 
language identifier along with each CodeDecode value. This Language field 
makes up a part of the compound key of the Code_Decode table. Each Code API 
lookup includes a system level call to retrieve the Language system variable. 
30 This value is used as part of the call to retrieve the values given the correct 
language. 
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Maintaining Language Localization Setting 

A link to the Language system environment variable to the language keys is 
5 stored on each CodeDecode. This value is modified at any time by the user 
simply by editing the regional settings User Interface available in the Microsoft 
Windows Control Panel folder. 

10 

Codes Expiration Approach 

Handling Time Sensitive Codes becomes an issue when filling controls with a list 
of values. One objective is to only allow the user to view and select appropriate 
15 entries. The challenge lies in being able to expire Codes without adversely 

affecting the application. To achieve this, consideration is given to how each UI 
will decide which values are appropriate to show to the user given its current 
mode. 

20 The three most common UI modes that affect time sensitive codes are Add Mode, 
View Mode, and Edit Mode. 

Add Mode 

In Add Mode, typically only valid codes are displayed to the user as selection 
25 options. Note that the constant, cmValidCodes, is the default and will still work 
the same even when this optional parameter is omitted. 

Set colStates = objArch.CodesMan.FillControl(frmCurrentForm.cboStates, 
cmCatStates, 
30 cmLongDecode, cmValidCodes) 
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View Mode 

In View Mode, the user is typically viewing results of historical data without 
direct ability to edit. Editing selected historical data launches another UI. Given 
this the controls are filled with valid and expired codes, or in other words, non- 
5 pending codes. 

Set colStates = objArch.CodesMan.FillControl(frmCurrentForm.cboStates, 
cmCatStates, 

cmLongDecode, cmNonPendingCodes) 

10 

Edit Mode 

In Edit Mode, changes are allowed to valid codes but also expired codes are 
displayed if already assigned to the entity. 

15 Dim colAssignedCodes As New cCollection 

colAssignedCodes.AddHistoricalAddress.State 

Set colStates = objArch.CodesMan.FillControl(frmCurrentForm.cboStates, 
cmCatStates, 

cmLongDecode, cmValidCodes, colAssignedCodes) 



Updating Local CodeDecodes 

25 The Local CodeDecode tables are kept in sync with central storage of 

CodeDecodes. The architecture is responsible for making a check to see if there 
are any new or updated code decodes from the server on a regular basis. The 
architecture also, upon detection of new or modified CodeDecode categories, 
returns the associated data, and performs an update to the local database. Figure 

30 7 is a logic diagram for this process 700. 
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After an API call, a check is made to determine if the Arch is initialized 702. If it 
is a check is made to determine if the Freshness Interval has expired 704. If the 
Freshness Interval has not expired, the API call is complete 706. However, if 
either the Arch is not initialized or the Freshness Interval has expired, then the 
5 "LastUpdate" fields for each category are read from the CodeDecode and passed 
to the server 708. Then new and updated catagories are read from the database 
710. Finally the Local database is updated 712. 

Code Access APIs 

10 

The following are APIs located on the interface of the Arch Object 200 named 
CodesMan 500. 

GetCodeObject(nCategory, sCode); 
GetCategoryCodes(nCategory) ; 
15 FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], 
[colAssignedCodes]). 

GetCodeObject: Returns a valid CCode object given a specific category and 
code. 

20 

Syntax: 

GetCodeObject(nCategory, sCode) 
25 Parameters: 

nCategory: The integer based constant which classified these CodeDecodes 
from others. 

sCode: A string indicating the Code attribute of the CodeDecode object. 

30 

Example: 

frmCurrentForm.lblState = objArch. CodesMan. GetCodeObject {cmCatStates, 
" IL " ) . LongDecode 

35 

GetCategoryCodes: Returns a collection of CCode objects given a valid 
category 

Syntax: 

40 

GetCategoryCodes(nCategory) 
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Parameters: 



nCategory: The integer based constant which classified these CodeDecodes 
5 from others. 



Example: 

Dim colMyStates As CCollection 
10 Set colMyStates = obj Arch . CodesMan . GetCategory (cmCatStates ) 

FillControl: This API is used to fill listboxes or comboboxes with values from a 
list of CodeDecodes. Returns a collection for subsequent lookups to Code 
objects used to fill controls. 

15 

Syntax: 

FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes]) 
20 Parameters: 



ctlControl: A reference to a passed in listbox or combobox. 

nCategory: The integer based constant which classified these CodeDecodes 

from others. 

nFillType: The attribute of the CodeDecode which you want to fill. Valid 
values include: 

cmCode 

cmShortDecode 
cmLongDecode 

nCodeStatus: Optional value which filters the Code Decodes according to 
their Effective and Expiration dates. Valid constants include the following: 

cmAllCodes Pending + Valid + Expired Codes 

cmPendingCodes Codes whose effective date is greater than the 
current date 

cmValidCodes Mot Pending or Expired Codes 

cmExpiredCodes Codes whose expired date is greater than the < 
date 

cmNonPendingCodes Valid + Expired Codes 

cmNonValidCodes Pending + Expired Codes 

cmNonExpiredCodes Pending + Valid Codes 

colAssignedCodes: Used when filling a control which should fill and 
include assigned values. 



Example: 



'Declare an instance variable for States collection on object 
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'Call FillControl API, and set local collection inst var to collection of codes 
which were used to fill the control. This collection will be used for 
subsequent lookups. 

Set colStates = objArch . CodesMan . FillControl ( frmCurrentForm.cboStates, 
5 cmCatStates, cmLongDecode) 

'Below shows an example of looking up the Code value for the currently selected state. 

With frmCurrentForm.cboStates 
If .Listlndex > -1 Then 
10 Dim objCode As CCode 

Set objCode = colStates (. ItemData (. Listlndex) ) 
sStateCode = objCode. Code 
End If 
End With 

15 

Relational Codes Access APIs 

20 Code objects returned via the "GetCodeObject" or "GetCategoryCodes" APIs can 
have relations to other code objects. This allows for functionality in which codes 
are associated to other individual code objects. 

The APIs used to retrieve these values are similar to those on the CodesMan 
25 interface. The difference, however is that the methods are called on the Codes 
object rather that the CodesManager interface: Listed below again are the APIs. 

GetCodeObject(nCategory, sCode); 
GetCategoryCodes(nCategory); 
30 FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], 
[colAssignedCodes]). 

Given below is some sample code to illustrate how these APIs are also called on 
Code objects. 

35 

GetCodeObject Example: 

Dim objBondCode As CCode 

Set objBondCode = ob j Arch. CodesMan. GetCodeObj ect (cmCatLOB, "B") 
40 Dim objSuretyCode As CCode 

Set objSuretyCode = objBondCode. GetCodeObj ect (cmCatSupplement , ^BOl") 
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GetCategory Example: 

Dim objBondCode As CCode 

Set objBondCode = objArch.CodesMan.GetGodeObject (cmCatLOB, "B") 
5 Dim colSupplements As CCollection 

Set colSupplements = objBondCode. GetCategory (cmCatSupplement) 

FillControl Example: 

10 Dim objBondCode As CCode 

Set objBondCode = objArch. CodesMan . GetCodeObj ect (cmCatLOB, "B") 
Dim colSupplements As CCollection 

Set colSupplements = objBondCode . FillControl ( frmForm. cboSupplements, 
cmCatSupplements , 
15 cmLongDecode ) 

MESSAGE LOGGING 

20 The message logging architecture allows message logging in a safe and consistent 
manner. The interface to the message logging component is simple and 
consistent, allowing message logging on any processing tier. Both error and 
informational messages are logged to a centralized repository. 

25 Abstracting the message logging approach allows the implementation to change 
without breaking existing code. 

Best Practices 

Messages are always logged by the architecture when an unrecoverable error 
30 occurs (i.e., the network goes down) and it is not explicitly handled. Message 
logging may be used on an as-needed basis to facilitate the diagnosis and fixing 
of SIRs. This sort of logging is especially useful at points of integration between 
classes and components. Messages logged for the purpose of debugging have a 
severity of Informational, so as not to be confused with legitimate error 
35 messages. 



40 
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Usage 

A message is logged by calling the LogMessage() function on the architecture. 

Description of Parameters: 

vMsg: the standard architecture message 

5 lSeverity: the severity of the message 

sClassName: the name of the class logging the message 

sMethodName: the name of the method logging the message 

sVersion: the version of the binary file (EXE or DLL) that contains the method 

logging the message 

10 lErrorNum: the number of the current error 

sText: an optional parameter containing the text of the message. If omitted, the 
text will be looked up in a string file or the generic VB error description will be 
used. 

sText: an optional parameter containing the text of the message. If omitted, the 
15 text will be looked up in a string file or the generic VB error description will be 
used. 

lLoggingOptions : an optional parameter containing a constant specifying where 
to log the message (i.e., passing cmLogToDBAndEvent Viewer to LogMessage 
will log the error to the database and the event viewer.) 

20 Logging Levels 

Before a message is logged, its severity is compared to the log level of the current 
machine. If the severity of the message is less than or equal to the log level, then 
the message is logged. 

25 Valid values for the log level are defined as an enumeration in VB. They 
include: 



Value 


Name 


Description 


Example 


0 


CmFatal 


A critical condition that closes or 
threatens the entire system 


Application Server 
crash 


1 


CmSevere 


A condition that closes or threatens a 


Network failure 
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major component of the entire system 




2 


CmWarning 


A warning that something in the system 
is wrong but it does not close or 
threaten to close the system 


Optimistic locking 
error 


3 


Cmlnformation 
al 


Notification of a particular occurrence 
for logging and audit purposes 


Developer debugging 
information 



Example 



If Err. Number <> 0 Then 
1 log message 

Arch. LogMan . LogMes sage (vMsg, cmSeverityFatal , "COrganizationCTLR" , 
"InitForm" , 

GetVersion ( ) , Err. Number, Err .Description) 

1 re-raise the error 
Err. Raise Err. Number 
End If 



Database Log 

The database log table is composed of the following fields: 

15 



Field Name 


Description 


N MSG ID 


Unique ID of the message 


D MSG 


Date the message occurred 


C ERR SEV 


Severity of the error 


N USER ID 


Name of user when error occurred 


N_MACH_ID 


Name of the machine that the error occurred on 


M CLASS 


Name of the class that the error occurred in 


M METHOD 


Name of the method that the error occurred in 


N CMPNT VER 


Version of the binary file that the error occurred in 


CJERR 


Number of the error 


T MSG 


Text of the message 



20 Local Log 

Messages are always logged to the application server's Event Log; however this 
is not necessarily true for the database as noted by the optional parameter passed 
to LogMessage, lLoggingOptions. An administrator with the appropriate access 
rights can connect to the MTS application server remotely and view its Event 
25 Log. Only one MTS package contains the Event Log Component, so that errors 
will all be written to the same application server Event Log. 
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Events logged via Visual Basic always have "VBRuntime" as the source. The 
Computer field is automatically populated with the name of the computer that is 
logging the event (i.e., the MTS application server) rather than the computer that 
5 generated the event (typically a client computer). 

The same event details that are written to the database are formatted into a 
readable string and written to the log. The text "The VB Application identified 
by . . . Logged:" is automatically added by VB; the text that follows contains the 
10 details of the message. 

DATA ACCESS 

15 All but a few exceptional cases use the "ExecuteQuery" API. This API covers 
singular database operations in which there exists a single input and a single 
output. Essentially should only exclude certain batch type operations. 

The Data Access Framework serves the purposes of performance, consistency, 
20 and maintainability. 

Performance 

The "ExecuteQuery" method incorporates usage patterns for using ADO in an 
efficient manner. Examples of these patterns include utilization of disconnected 
25 recordsets, and explicitly declaring optional parameters which result in the best 
performance. 

Consistency 

This method provides a common interface for development of data access. Given 
30 a simple and stable data access interface, best practices can be developed and 
disseminated. 
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Maintainability 

Since the method is located in a single location, it is very modularized and can be 
maintained with little impact to its callers. 

Application servers often use the ActiveX Data Objects (ADO) data access 
interface. This allows for a simplified programming model as well as enabling 
the embodiments to utilize a variety of data sources. 



The "ExecuteQuery" Method 

Overview 

The "ExecuteQuery" method should be used for most application SQL calls. 
This method encapsulates functionality for using ADO in a effective and 
efficient manner. This API applies to situations in which a single operation 
needs to be executed which returns a single recordset object. 

Syntax 

Set obj = ExecuteQuery (vMsg, nTranType, sSQL, [nMaxRows] , [adoTransConn] , 
[args] ) 



vMsg 

This parameter is the TechArch struct. This is used as a token for 
information capture such as performance metrics, error information, 
and security. 

nTranType 

An application defined constant which indicates which type of 

operation is being performed. Values for this parameter can be one 

of the following constants: 

cmS elect 
cmSelectLocal 
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cmUpdate 

cmlnsert 

cmDelete 

5 sSQL 

String containing the SQL code to be performed against the DBMS. 

nMaxRows (Optional) 

Integer value which represent the maximum number of records that the 

10 recordset of the current query will return. 



adoTransConn (Optional) 

An ADO Connection object. This is created and passed into execute 
query for operations which require ADO transactional control (see "Using 
15 Transactions" section) 

args (Optional) 

A list of parameters to be respectfully inserted into the SQL 

statement. 

20 

Implementation 

In one embodiment of the present invention the "ExecuteQuery" method resides 
within the MservArch.bas file. This file should be incorporated into all 
25 ServerComponent type projects. This will allow each server component access to 
this method. 

Note: Since this method is a public method in a "bas" module, it is globally 
available from anywhere in the project. 



Public Function ExecuteQuery (vMsg As Variant, _ 

nTranType As TranTypes, _ 
sSQL As String, _ 

Optional nMaxRows As Integer = 0, _ 
Optional adoTransConn As ADODB. Connection, _ 
Optional colArguments As CCollection) As Variant 
On Error GoTo ErrorKandler 

Const cmMethodName As String = "ExecuteQuery" 

StartTimeLogger vMsg, cmTimerldDBTotal , cmClassName, cmMethodName 
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' find out if this call is an isolate operation or 
'part of an ADO (not MTS) transaction 
Dim isAtomicTrans As Boolean 
isAtomicTrans = adoTransConn Is Nothing 

Dim nRecordsAf fected As Integer 
Dim adoRS As New ADODB . Recordset 
Dim adoConn As ADODB. Connect ion 
Dim lAuxErrNumber As Long 

'open a new connection or keep using the passed i 
Set adoConn = I If (isAtomicTrans, Mew ADODB .Connection, adoTransConn) 

If isAtomicTrans Then 

adoConn. Open cmODBC_Connect 

'ADO will wait indefinitely until the execution is complete during 
performance 

testing 

#If IsPerfTest Then 

adoConn. CommandTimeout = 0 
#End If 
End If 

'Make sure date args are formatted for DB2 if appropriate 
If Not colArguments Is Nothing Then _ 

Set colArguments = FormatArgsForDB2 (colArguments) 

■merge the passed in arguments with the SQL string 
sSQL = MergeSQL ( s SQL , colArguments) 

Debug. Print Time & ": " & sSQL 

'execute the SQL statement depending on the transaction type 
Select Case CStr (nTranType) 
Case cmSelect 

adoRS .MaxRecords = nMaxRows 

adoRS.CursorLocation = adUseClient 

adoRS.Open sSQL, adoConn, adOpenForwardOnly, adLockReadOnly, 

adCmdText 

Set adoRS.ActiveConnection = Nothing 
Set ExecuteQuery = adoRS 
Case cmSelectLocal 

adoRS . MaxRecords = nMaxRows 
adoRS.CursorLocation = adUseClient 

adoRS.Open sSQL, adoConn, adOpenStatic, adLockBatchOptimistic , 

adCmdText 

Set adoRS.ActiveConnection = Nothing 
Set ExecuteQuery = adoRS 
Case cmlnsert 

Set adoRS = adoConn. Execute (sSQL, nRecordsAf fected, adCmdText) 
If nRecordsAf fected <= 0 Then Err. Raise cmErrQuerylnsert 
Set adoRS = Nothing 



ExecuteQuery = nRecordsAf f ected 
Case cmUpdate, cmDelete 

Set adoRS = adoConn. Execute (sSQL, nRecordsAf f ected, adCmdText) 

If nRecordsAf f ected <= 0 Then Err. Raise cmErrOptimisticLock 

Set adoRS = Nothing 

ExecuteQuery = nRecordsAf f ected 
Case cmSpFileNote 

Set adoRS = adoConn. Execute (sSQL, nRecordsAf f ected, adCmdText) 

Set adoRS = Nothing 
Case Else 

Err. Raise cmErrlnvalidParameters 
End Select 

StopTimeLogger vMsg, cmTimerldDBTotal , cmClassName , cmMethodName 
Exit Function 

ErrorHandler : 

Dim objArch As Object 

Set objArch = CreateObj ect < " cmArch . CTechArch" ) 

Select Case CStr(Err) 

Case cmErrQuerylnsert, cmErrOptimisticLock, cmErrlnvalidParameters 

Err. Raise Err 

Case cmErrDSNNotFound 

Dim sMsgText As String 

sMsgText = "Data Source Name not found." & vbCrLf &"("&_ 
CStr (objArch. RegMan . GetServerDSN) & " )" 

1 Create a new message log and log the message 

objArch. LogMan.LogMessage vMsg, cmSeverityFatal , cmClassName , 
cmMethodName , 

GetVersion ( ) , cmErrDSNNotFound, sMsgText, 

cmLogToEventViewerOnly 



lAuxErrNumber = adoConn. Errors (0 ) .NativeError 'The error code is 

stored since 

40 when closing the 

collection it will 

If adoConn. State <> adStateClosed Then adoConn. Close 

45 Err. Raise cmErrDSNNotFound, , sMsgText 

Case Else 

' Create a new message log and log the message 
objArch. LogMan.LogMessage vMsg, cmSeverityFatal, cmClassName, 
cmMethodName , 

50 GetVersionO , Err. Number, Err .Description, 

cmLogToEventViewerOnly 
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lAuxErrNumber = adoConn. Errors ( 0 ) -NativeError 'The error code is 

stored since 

when closing the 

conection it will 

5 be lost 

If adoConn. State <> adStateClosed Then adoConn. Close 
Err. Raise lAuxErrNumber 
End Select 
End Function 

10 

Selecting Records 

ExecuteQuery utilizes disconnected recordsets for "Select" type statements. This 
15 requires that the clients, particularly the CCA's contain a reference to ADOR, 
ActiveX Data Object Recordset. This DLL is a subset of the ADODB DLL. 
ADOR contains only the recordset object. 

Using disconnected recordsets allows marshalling of recordset objects from sever 
20 to client. This performs much more efficiently than the variant array which is 
associated with using the "GetRows" API on the server. This performance gain 
is especially apparent when the application server is under load of a large number 
of concurrent users. 

25 Sample from Client Component Adapter (CCA) 

Dim vAns as Variant 

Dim adoRS As ADOR. Recordset 

Set adoRS = obj Server. PerformSelect (vMsg, nld) 
30 If objRS . EOF Then 

Set objRS = Nothing 

Exit Function 
End If 

35 vAns = adoRS. GetRows 

Set adoRS = Nothing 

'Marshall vAns into objects 

40 

Sample from Server Component 

Private Const cmCustSQL = "Select * from Customer where id = ?" 
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Public Function Perf ormSelect (vMsg, nld) as Variant 

Dim colArgs as CCollection 

Set colArgs = New Ccollection 
5 colArgs. Add nld 

Set PerformSelect = ExecuteQuery (vMsg, cmSelect, sCustSQL, , , colArgs) 
End Function 

Code Clip from ExecuteQuery (Select Section) 

10 

Case cmSelect 

adoRS.MaxRecords = nMaxRows 
adoRS.CursorLocation = adUseClient 

adoRS.Open sSQL, adoConn, adOpenForwardOnly, adLockReadOnly, adCmdText 
15 Set ExecuteQuery = adoRS 



Inserting Records 

20 

Inserting records requires certain information pertaining to optimistic locking. 
On the server a unique value is requested to indicate the last time modified. This 
unique value is returned back to the requestor such that it can be used to later 
database operations. 

25 

Sample from Client Component Adapter (CCA) 

Dim vNewTS as Variant 

vNewTS = ob j Server. Per f ormlnsert (vMsg, nld, sName) 
'Set object's TiirteStamp to vNewTS 

30 

Sample from Server Component 

Private Const cmCustlnsertSQL = "Insert Customer (nld, Name, LastUpdated) 
Values (?, ' ?', ?>" 

35 Public Function Perf ormlnsert (vMsg, nld, sName) As Variant 

Dim lCurrTS as Long 

ICurrTS = GetTimeStamp 

Dim colArgs as CCollection 

Set colArgs = New Ccollection 
40 colArgs. Add nld 

colArgs . Add sName 

colArgs. Add ICurrTS 

ExecuteQuery (vMsg, cmlnsert, sCustlnsertSQL, , , colArgs) 
Performlnsert = ICurrTS 



Code Clip from ExecuteQuery (Insert Section) 



Case cmlnsert 

Set adoRS = adoConn. Execute ( sSQL, nRecordsAf fected, adCmdText) 
If nRecordsAf fected <= 0 Then Err. Raise cmErrQuerylnsert 
Set adoRS = Nothing 
ExecuteQuery = nRecordsAf fected 



Updating Records 

Updating records requires certain information pertaining to optimistic locking. 
On the server a unique value is requested to indicate the last time modified. Also 
the last read timestamp is used to validate, during the update, that the record has 
not been modified since last time read. 

Sample from Client Component Adapter (CCA) 

Dim vNewTS as Variant 

vNewTS = obj Server. Per f ormUpdate tvMsg , 1, "Rick', 8907654) 
"Set object's TimeStamp to vNewTS 

Sample Code Clip from Server Component 

Private Const cmCustUpdateSQL = _ 

"Update Customer Set Name = 1 ? ' , LastUpdated = ? * & _ 
"Where Id = ? * & _ 
"And LastUpdated = ? " 

Public Function Perf ormUpdate (vMsg, nld, sName, lLastTS) As Variant 
Dim lCurrTS as Long 
lCurrTS = GetTimeStamp 
Dim colArgs as CCollection 
Set colArgs = New Ccollection 
colArgs.Add sName 
colArgs. Add lCurrTS 
colArgs.Add nld 
colArgs.Add lLastTS 

Perf ormUpdate = ExecuteQuery (vMsg, cmUpdate, sCustUpdateSQL, , , colArgs) 
PerformUpdate = lCurrTS 
End Function 



Code Clip from ExecuteQuery (Update Section) 



;e cmUpdate 

Set adoRS = adoConn . Execute { sSQL, nRecordsAf fected, adCmdText) 
If nRecordsAf fected < 0 Then Err. Raise cmErrOptimisticLock 
iteQuery = nRecordsAf fected 
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5 



Deleting Records 

In deleting records the last read timestamp is used to validate, during the delete, 
that the record has not been modified since last time read. 

Sample from Client Component Adapter (CCA) 

Dim vAns as Variant 

vAns = objServer.PerformDelete(vMsg, nld , lLastTS) 

Sample from Server Component 

Private Const cmCustDeleteSQL = _ 
"Delete From Customer " & _ 
"Where Id = ? " & _ 
"And LastUpdated = ? " 

Public Function Perf ormDelete (vMsg, nld lLastTS) As Variant 
Dim colArgs as CCollection 
Set colArgs = New Ccollection 
colArgs.Add nld 
colArgs. Add lLastTS 

Perf ormDelete = ExecuteQuery (vMsg, cmDelete, cmCustDeleteSQL) 
Exit Function 

Code Clip from ExecuteQuery (Delete Section) 

Case cmDelete 

Set adoRS = adoConn . Execute ( sSQL , nRecordsAf f ected, adCmdText) 
If nRecordsAf f ected < 0 Then Err. Raise cmErrOptimisticLock 
ExecuteQuery = nRecordsAf f ected 



DATABASE LOCKING FRAMEWORK 



Database Locking ensures the integrity of the database in a multi-user 
environment. Locking prevents the common problem of lost updates from 
multiple users updating the same record. 



40 
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Solution Options 

Pessimistic Locking 

This policy of locking allows the first user to have full access to the record while 
5 following users are denied access or have read only access until the record is 
unlocked. There are drawbacks to this method of locking. It is a method that is 
prone to deadlocks on the database as well poor performance when conflicts are 
encountered. 

Optimistic Locking 

10 The optimistic approach to record locking is based on the assumption that it is not 
normal processing for multiple users to both read and update records 
concurrently. This situation is treated as exceptional processing rather than 
normal processing. Locks are not actually placed on the database at read time. A 
timestamp mechanism is used at time of update or delete to ensure that another 

15 user has not modified or deleted the record since you last read the record. 

A preferred embodiment of the present invention uses an optimistic locking 
approach to concurrency control. This ensures database integrity as well as the 
low overhead associated with this form of locking. Other benefits to this method 
20 are increased availability of records to multiple users, and a minimization of 
database deadlocks. 

Table candidates for concurrency control are identified during the "Data 
Modeling Exercise". The only table which is updated concurrently is the 
25 Optimistic Locking mechanism. Once these are identified, the following is added 
to the application. 

Add "N_Last_Updt" field to table in database; 
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Error Handling routines on those operations which modify or delete from this 
table; and 

Display/Notification to user that the error has occurred. 
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Usage 

The chart below describes the roles of the two basic types of components to 
enable optimistic locking. 
5 Assumption: The optimistic locking field is of type Date and is named 



"N_Last_Updt" 





Client Components 


Server Components 


Read 

Access 


Store N_JLast_Updt value in the 
business object for use in possible 
updates or deletes. 


Retrieve data (Always including N_Last_Updt field). 

SELECT Id, FirstName, N_Last_Updt 
FROM Customer 
WHERE id = 10; 


Inserts 


Normal 


Dim lCurrTS As Double 
lCurrTS = GetTimeStamp 

INSERT INTO Customer (Id, FirstName, N_Last_Updt) 
VALUES (1, "Rick", lCurrTS); 

Return new timestamp (lCurrTS) as well as new Id 


Updates 


Pass previously read timestamp to 
identify whether row was modified. 
This is in addition to a unique identifier 
and whatever data needs to be updated. 

Handle exception if record has been 
previously modified. 

Notify user of conflict. 

Rollback any changes. 


Dim lCurrTS As Double 
lCurrTS = GetTimeStamp 

UPDATE Customer 

SET firstName = "Richard", 

N_Last_Updt = lCurrTS 
WHERE id = 1 

AND LastUpdate = lasfReadTimestamp; 

If no rows are affected, handle and propagate error back 
out to the client. 

Return new timestamp (lCurrTS) 


Deletes 


Pass previously read timestamp to 
identify whether row was modified. 
This is in addition to a unique identifier 

Handle exception if record has been 
previously modified. 

Notify user of conflict. 

Rollback any changes. 


DELETE Customer 
WHERE id = 1 

AND N_Last_Updt = lasfReadTimestamp; 

If no rows are affected, handle and propagate error back 
out to the client. 
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LARGE RESULT SET 

When retrieving records from a database, if the search criteria is too broad, the 
amount of data required to be retrieved from the database and passed across the 
5 network will affect user perceived performance. Windows requesting such data 
will be slow to paint and searches will be slow. The formation of the database 
queries is made such that a workable amount of data is retrieved. There are a few 
options for addressing the problems that occur from large result sets. The options 
are given below in order of preference. 

10 

Redesign the interface/ controller to return smaller result sets. By designing the 
controllers that present the database queries intelligently, the queries that are 
presented to the database server do not return a result set that is large enough to 
affect user perceived performance. In essence, the potential to retrieve too many 
15 records indicates that the UIs and the controllers have been designed differently. 
An example of a well designed Search UI is one where the user is required to 
enter in a minimum search criteria to prevent an excessively large result set. 

Have Scrollable Result Sets. The scrolling retrieval of a large result set is the 
20 incremental retrieval of a result subset repeated as many times as the user 
requests or until the entire result set is obtained. Results are retrieved by the 
Bounded Query Approach where the first record is determined by a where clause 
with calculated values. 

25 

Scrollable Result Set Client requirements 

Preferred UI 

The preferred displays are as follows: 

30 

Returned results are displayed in a GreenTree List Box; 
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An action button with the label More... is provided for the user to obtain the 
remaining results; 

5 The More button is enabled when the user has performed an initial search and 
there are still results to be retrieved; 

The More button is disabled when there are no more results to retrieve; 

10 The List Box and the Action button is contained within a group box to provide a 
visual association between the button and the List Box. 

Bounded Query 

15 Queries that are implemented with the limited result sets are sent to the server. 
The server implements the executeQuery method to retrieve the recordset as 
usual. Limited result queries have an order by clause that includes the business 
required sort order along with a sufficient number of columns to ensure that all 
rows can be uniquely identified. The recordset is limited by the nMaxRows 

20 variable passed from the client incremented to obtain the first row of the next 
result set. The return from the component is a recordset just the same as with a 
query that is not limited. The CCA 208 creates the objects and passes these back 
to the controller 206 . The Controller 206 adds this returned collection of object 
to its collection of objects (an accumulation of previous results) and while doing 

25 so will performs the comparison of the last object to the first object of the next 
row. The values necessary to discriminate the two rows are added to the variant 
array that is necessary to pass to the component for the subsequent query. 

The Controller 206 on the client retains the values for nMaxRows, the initial SQL 
30 statement, and array of values to discern between the last row of the previous 

query and the first row of the next query. The mechanism by which the controller 



206 is aware that there are more records to retrieve is by checking the number of 
results is one greater than the max number of rows. To prevent the retrieval of 
records past the end of file, the controller 206 disables these functions on the UL 
For example, a command button More on the UI, used to requested the data, is 
disabled when the number of objects returned is less than nMaxRows + 1 . 

Application responsibility 

Server 

The Server component is responsible for creating a collection of 
arguments and appending the SQL statement to add a where clause that will be 
able to discriminate between the last row of the previous query and the first row 
of the next. 

CCA 

The CCA 208 processes the recordset into objects as in non limited 
queries. The CCA 208 forwards the variant array passed from the Controller 206 
to identify the limited results. 

Controller 

The controller 206 has the responsibility of disabling the More control 
when the end of file has been reached. The controller 206 populates the variant 
array (vKeys) with the values necessary to determine start of next query. 

Example 

A CCA 208 is coded for a user defined search which has the potential to 
return a sizable result set. The code example below implements the Bounded 
Query approach. 



On the Server the developer codes the query as follows: 
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Public Function RetrieveBusinessObjects (vMsg As Variant, ByVal sSql As String, 
ByVal nMaxRows As Integer, Optional ByVal vKeys As Variant) As Recordset 
On Error GoTo ErrorHandler 

5 'Declare local constants 

Const cmMethodName As String = "RetrieveBusinessObjects" 



■Declare local variables 
Dim cmClassName As String 
Dim colArgs As New CCollectic 



cmClassName = "CSRSTestComp" 



' fill argument collection 

Set colArgs = ArgumentsForBusinessObj ect (vKeys , 
'increment nMaxRows to obtain row for comparisoi 
nMaxRows = nMaxRows + 1 



"se^RetrieveBusinessObjects = ExecuteQuery (vMsg, cmSelectLocal , sQuery, 
nMaxRows, , colArgs) 



■Tell MTS we're done 
30 GetObjectContext.SetComplete 
Exit Function 

ErrorHandler: 

Select Case Err. Number 

35 

Case Else 

Dim iResumeCode As Integer 

iResumeCode = GeneralErrorHandler (vMsg, cmServer, cmClassName, 
cmMe thodName ) 
40 Select Case iResumeCode 

Case cmErrorResume 

Resume 
Case cmErrorResumeNext 
Resume Next 
45 Case cmErrorExit 

Exit Function 
Case Else 

GetObj ectContext . SetAbort 
Err. Raise Err. Number 
50 End Select 

End Select 
End Function 

To determine the additional where clause necessary to determine the starting 
55 point of the query, the following method is added: 



Private Function ArgumentsForBusinessObj ect (vKeys As Variant, sSql As string ) 
As CCollection 

Dim colArgs As Ccollection 
60 Const cmGreaterThanWhereString As String ="?>?" 

Const cmGreaterThanOrEqualWhereString As String ="?>=? AND " 

1 initialize local variables 
Set colArgs = New Ccollection 
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sSql = sSql + "WHERE" 



With colArgs 

If vKeys(O) <> Empty Then 

. Add ( " N_TASK_TEMPL_ID " ) 
.Add (vKeys(O)) 

End If 

'If vKeys(l) <> Nothing Then 
' .Add value2 fieldName 
' . add vKeys ( 1 ) 

sSql = sSql + cmGreaterThanOrEqualWhereString 
'End If 

'If vKeys(2) <> Nothing Then 
' .Add value3 fieldName 
' .add vKeys (2) 

sSql = sSql + cmGreaterThanOrEqualWhereString 
■End If 
End With 



'finalize SQL £ 
sSql = sSql + cmGreaterThanWhereString 



Set ArgumentsForBusinessObj ect = 



On the CCA 208, allowance must be made for the passing of the vKeys 

Public Function RetrieveBusinessObjects(vMsg As Variant, sSql As String, 
nMaxRows As Integer, Optional ByVal vKeys As Variant) As CCollection 



Set percmpComponent = New CSRSTestComp 
Dim i As Integer 

Set adoRS = percmpConponent .RetrieveBusinessObjects (vMsg, sSql, nMaxRows, 
vKeys ) 

'convert recordset to business objects 

adoRS.MoveFirst 

Do Until adoRS . EOF 

Call ConvertToBusinessObject 

adoRS . MoveNext 

'return the collection of business objects 

Set RetrieveBusinessObjects = dictBusinessObj ect 

Set dictBusinessObj ect = New CCollection 
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End Function 



5 The controller initiates the query and updates the variant array of keys and form 
204 properties based on the return. In addition to the code shown for the example 
below, the More Control is enabled if the search is cleared. 

'declare instance variables 
10 Private nMaxRows As Integer 

Dim interimResults As CCollection 
Dim vResults As CCollection 
Dim vKeys(3) As Variant 

15 'declare Constants 

Private Const nDe fault Amount As Long = 50 

Private Const cmRetrieveBusinessObjectSQL = "SELECT * FROM NODE_RULE ORDER BY 

_ N_TASK_TEMPL_ID" 

20 

During class initialization perform the following: 

Public Sub Class_init() 

25 1 obtain settings from registry 

nMaxRows = CInt (GetSetting ( cmRegApp , cmRegArchSection, 
cmLimitedResultAmountKey, IDef aultAmount) ) 

Call resetSearch 
30 Set objCCA = New {CCA class name} 

End Sub 

Search reset functionality is kept outside of initialization so this may be called 
35 from other parts of the application. 

Public Sub resetSearch () 
Dim I as Integer 

Set vResults = New Ccollection 
For 1 = 0 To 3 
40 Set vKeys(I) = Empty 

Next 

Set vKeys ( 0 ) = Empty 

f ntiCurrentForm. cmdMore . Enabled = True 

45 End Sub 

Public Sub RetrieveBusinessObjects ( ) 

Const cmMethodName As String = " retrieveBusinessObj ects " 
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Call RetainMouse 

1 get arch message 
Dim vMsg As Variant 

vMsg = obj App . obj Arch . AsMsgStruct ( ) 

' call the component 
Dim pair As CArchPair 

'Declare local variables 
Dim sSql As String 
Dim colArgs As CCollection 
Dim cmClassName As String 



Set interimResults = objCCA. RetrieveBusiness0b3ects (vMsg, 
cmRetrieveBusinessObjectSQL, nMaxRows, vKeys) 

ctr = ProcessObjectCollection 

' stop if size of return is less than the maximum 

If ctr < nMaxRows + 1 Then frmCurrentForm. cmdMore .Enabled = False 

' restore pointer 

Screen. MousePointer = lPrevPtr 
End Sub 

In order to retain the values to discriminate between the last row of the result set 
and the first row of the next the following method on the controller is used: 



Private Function ProcessObj ectCollection ( ) As Integer 

1 merge results with the instance variable for the collection 
Dim ctr As Integer 
ctr = 0 

For Each element In interimResults 
ctr = ctr + 1 

■ retain Keys for subsequent Queries 
With element 
Select Case ctr 
Case nMaxRows 

'store all values that may be used for row comparison 
vKeys(O) = .Nodeld 

'add last object to collection 
vResults.Add element 

Case nMaxRows + 1 

'last object only used for comparison 

'If the proceeding value can be used to uniquely 

'identify row then delete value from array 

' THERE SHOULD BE N - 1 nested If statements where N = 
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' If .value2 <> vKeys(l) Then 
'vKeys(2) = Empty 

If .Nodeld <> vKeys(O) Then vKeys(l) = Empty 
'End If 
Case Else 

vResults.Add element 

End Select 
End With 

Next 

ProcessObjectCollection = ctr 
End Function 



Operation of example with data 



Joy 




Status 


Unique ID 


Andersen 


Closed 


22 


Jay 


Anderson 


Open 


12 


John 


Barleycorn 


Closed 


512 


John 


Barleycorn 


Open 


32 


Esther 


Davidson 


Open 


88 


David 


Dyson 


Closed 


98 


Bobby 


Halford 


Open 


234 


Steven 


Jackowski 


Closed 


4 


Kyle 


Johnsen 


Open 


65 


Jeff 


Johansen 


Open 


13 


Mary 


Johnson 


Closed 


24 


Larry 


Olsen 


Open 


21 


William 


O'Neil 


Closed 


29 


Jane 


Pick 


Open 


3285 



For this example let nMaxRows = 3. The business case calls for the result set to 
be ordered by the last name, and developer knows that any row can be uniquely 
identified by the FirstName, LastName, and Unique ID fields so the initial SQL 
added as a constant in the controller should be; 

SELECT * FROM Person ORDER BY LastName, FirstName, 

Unique_ID 



Initial Query 

The first query is sent with an empty vKeys Array. When the server receives 
this query, the method ArgumentsForBusinessObject identifies the elements as 
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being empty and does not populate the colArgs. The query is executed with the 
intial SQL unchanged. The recordset of size nMaxRows + 1 is returned to the 
CCA 208 and processed the same as non-limited results. The CCA 208 returns 
the collection of objects to the controller 206. The controller 206 proceeds to 

5 populate the vResults collection with the returned objects. vResults is the 

comprehensive collection of objects returned. When the last object of the first 
request is reached (at nMaxRows), the values are stored in vKeys as such; 
vKeys(O) = LastName (Barleycorn) 
vKeys(l) = FirstName ( John ) 

10 vKeys(2) = Unique_JX) (5 1 2) 

When the First Object of the next request is reached ( at nMaxRows +1), 
comparison of the object variables against the vKeys values is performed. 
Because the last names match, vKeys(2) will not be deleted and no further checks 
are performed. 

15 Subsequent Query 

The subsequent query will pass vKeys along with it. The server creates the 
collection of arguments from vKeys and append the sSql string in accordance. 
The sSql statement that is passed to execute query is 

SELECT * FROM Person ORDER BY LastName, FirstName, 

20 Unique_ID WHERE ? >= ? AND ? >= ? AND ? > ? 

This sSql and collection is included in the call to ExecuteQuery which merges 
the arguments with the string relying on the architecture method MergeSQL to 
complete the SQL statement. 

The starting point of the recordset is defined by the WHERE clause and the limit 
25 is set by the nMaxRows value. 



Query less restrictive WHERE criteria 

After the second query the last row of the query is David Dyson and the next 
is Bobby Halford. Because the last name is different, vKeys will be empty except 
30 for vKeys(O) = Dyson. 
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The ProcessObject Collection will populate vKeys as follows when processing 
nMaxRows object: 
vKeys(O) = LastName (Dyson) 
vKeys(l) = FirstName (David) 
5 vKeys(2) = Unique_ID (98) 

After identifying the differences between vKeys values and the nMaxRows + 1 
object the vKeys array is updated as follows: 
vKeys(O) = LastName (Dyson) 
10 vKeys(l) = Empty 
vKeys(2) = Empty 

The query that is returned from ArgumentsForBusinessObject is 

SELECT * FROM Person ORDER BY LastName, FirstName, 
15 Unique_ID WHERE ? > ? 

and the colArgs possessing the fieldname FirstName and the value ("David"). 
ExecuteQuery merges the arguments with the sql statement as before and returns 
the value. 

20 Ending 

After the fifth iteration the result set will only possess 2 records. When 
the controller 206 processes the returned collection the counter returned from 
ProcessObjectCollection is less than nMaxRows + 1 which indicates that all 
records have been retrieved. 
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SECURITY FRAMEWORK 

Implementation 

5 

Figure 8 shows a representation of the Security Framework 800 and its main 
components. 

It can be seen from Figure 8 that the Security object 802 is present at the Client 
10 and a Security API is provided at the server. The Security object 802 provides 
one method responsible for authorizing any operation, being given the vMsg 
structure, an operation ID and an optional parameter describing the operation's 
context. 

15 

Client 
User Authentication: 

User authentication is handled via a method located in the Security object 802 
20 called IsOperAuthorized. As the Application object loads, it calls the 

IsOperAuthorized method, with the operation being "Login", before executing 
further processing. This method subsequently calls a authentication DLL, which 
is responsible for identifying the user as an authorized user within the Corporate 
Security. 

25 

UI Controllers: 

The UI Controllers limit access to their functions by restricting access to specific 
30 widgets through enabling and disabling them. The logic for the enabling and 

disabling of widgets remains on the UI Controller 206, but the logic to determine 
whether a user has access to a specific functionality is located in the Security 
object 802 in the form of business rules. The UI Controller 206 calls the 
IsOperAuthorized method in order to set the state of its widgets. 
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Server 

Server security is implemented by restricting access to the data in three different 
5 ways: 

Server Security Method 

Server Components 222 call the IsOperAuthorized API in the Architecture before 
executing every operation. In all cases the Security object 802 returns a boolean, 
10 according to the user' s access rights and the business rules 

SQL Filtering 

Includes security attributes, like claim sensitiveness or public/private file note, 
into the SQL statements when selecting or updating rows. This efficiently 
15 restricts the resulting data set, and avoids the return of restricted data to the client. 

Description 

20 Any GUI related security is implemented at the Client using the Security object 
802. The information is available both at the Client Profile and Business Objects 
207 which enables the security rules to be properly evaluated. 

IsOperAuthorized is called to set widgets upon the loading of a UI or if there is a 
25 change of state within the UI. 

User authentication always is used by the Application Objects 202 in order to 
validate user privilege to launch the application. 

30 SQL Filtering is used in the cases where sensitive data must not even be available 
at the Client, or where there is a great advantage on reducing the size of the data 
set returned to the Client. 
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SQL Filtering is only used in very rare cases where performance is a serious 
concern. It is used carefully in order to avoid increased complexity and 
performance impacts because some queries can be cumbersome and embedding 
security on them could increase complexity even more. 

5 

Security Framework 

10 Overview 

The Security object 802 serves the purpose of holding hard coded business rules 
to grant or deny user access for various application functions. This information is 
returned to the UI controllers 206 which make the necessary modifications on the 
UI state. The ClientProfile object serves the purpose of caching user specific 
15 (and static) security information directly on the client. This information is 
necessary to evaluate the business rules at the Security object 802. 

Relationships 

20 

Figure 9 shows the relationships between the security element and other 
elements. 

Architecture Object 

25 The TechArch object is responsible for providing access and maintaining the 
state of the ClientProfile 902 and Security objects 802. The ClientProfile object 
902 is instantiated and destroyed in the TechArch 's initialization and terminate 
methods, respectively. This object is maintained through an instance variable on 
the TechArch object. 



30 
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ClnitCompCCA 

The CInitCompCCA object 904 provides two services to the architecture object 
200, it serves as an access point to the CInitComp Server 906, and it Marshalls 
the query result set into a ClientProfile object 902. 

5 

CInitComp 

The CInitComp server object 906 provides data access to the data that resides in 
the organization tables 908. This data is useful on the client to determine level of 
access to data based on hard coded business rules. 

10 

Organization Tables 

The Organization tables 908 contain user, employee and unit information 
necessary to build the hierarchy of information necessary to determine level of 
access to sensitive information. 

15 

Client Profile 

The ClientProfile object 902 serves the purpose of caching static, user specific 
security information directly on the client. This information is necessary to 
determine data access level of information to the user, which is accomplished by 
20 passing the necessary values to the Security object 802. 

Security Object 

The Security Object 802 contains business rules used to determine a user's access 
privileges in relation to specific functions. The object accepts certain parameters 
25 passed in by the various UI Controllers 206 and passes them to through the 

business rule logic which, in turn, interrogates the Client Profile object 902 for 
specific user information. 
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Client Profile 

Attributes 

5 The following are internal attributes for the Client Profile object 902. These 
attributes are not exposed to the application and should only be used by the 
Security object 802: 

• sProfile: 

10 

This attribute is passed by the legacy application at start-up and contains the 
user's TSIds, External Indicator, Count of Group Elements and Group 
Elements. It is marshalled into these attributes by request of the application 
objects. 

15 

• colSpecialUsers: 

This attribute caches information from a table containing special users which 
do not fit into one of the described roles, such as Organization Librarian. 
20 (e.g., Vice President or CEO of the corporation.) 

• sTSId: 

This is the current users' TSId, and it corresponds to his/her Windows NT Id. 
25 It is used to get information about the current logged on user from the 

Organizational Tables 908. 



30 



sEmployeeld: 



This corresponds to the user's employee Id, as stored in the Organizational 
tables 908. It is used against the passed in employee Id, in order to check 
relationship between performers and the current user. 

sEmployeeName, sEmployeeFirst, sEmployeeMI and sEmployeeLast: 

All these attributes correspond to the current user's name. 

dictClientPri vileges : 

This attribute contains a collection of identifiers that indicate what 
role/authority an individual plays/possesses. This value is used to identify the 
static role of the logged in user. 

These values are used for security business logic which grants or denies 
access based on whether the user is internal or external, or whether the user is 
in a given administrative role. Existing values are the following: 

• SC - Indicates sensitive Claim authority 

• CC - Indicates Change Claim status authority 

• MT - Indicates maintain F&C Templates authority 

• MO - Indicates maintain Organization authority 

• MR - Indicates maintain Roles authority 

The following are the proposed additions: 

• TA - Indicates authority to execute Task Assistant 

• FN - Indicates authority to execute FileNotes 

• CH- Indicates authority to execute Claim History 

• TL - Indicates authority to maintain Task Templates 
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• dictProxyList: 

5 This attribute contains an employees' reporting hierarchy. It is used to 

determine whether the current user/employee has permission to perform some 
action based on his/her relationship to other users/employees within their 
hierarchy. A business example of this is the case of a supervisor, who has 
rights to view information that his/her subordinates have access to. The 

10 relationship API's make use of dictProxyList to determine if the user assigned 

to the information is super or subordinate of the current user. 

• boollnternal: 

15 This attribute indicates whether the logged in user is external or internal. It is 

also marshalled from the sProfile attribute, passed in by the legacy 
application. 

Public Methods 

20 The following are the APIs exposed by the Client Profile object. These APIs are 
used for security checking by the Security object and should not be used by the 
developers in any portion of the application. 

• GetAuthorizedEmployees As Collection 

25 

This function returns a collection of employee Ids from the employees 
supervised by the current user. 

• IsSuperOf(sUserld) As Boolean 

30 

This API returns true if the logged in user is a super of the passed in user Id. 
It looks up the sUserld value inside the dictProxyList attribute. 
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• IsRelativeOf(sUserId) As Boolean 

This API returns true if the passed in user Id corresponds to either the logged 
in user or someone from the dictProxyList. 

• Islnternal As Boolean 

This API is used to grant or restrict the user to information based on whether 
the data is private to the organization whether the user is internal or external. 

• IsInRole(sRole) As Boolean 

This API looks up the appropriate sRole value contained within the 
dictClientRoles attribute to determine whether the current user is authorized 
to perform that role. 

The following accessors are used to get data from the Client Profile's object: 

• Userld: returns sTSId 

• Employeeld: return sEmployeeld 

• EmployeeName: returns sEmployeeName 

• EmployeeFirstName: returns sEmployeeFirst 

• EmployeeLastName: returns sEmployeeLast 

• EmployeeMiddlelnitial: returns sEmployeeMI 

• ExpandTree: returns boolExpandTreePreference 

• TemplatePathPreference: returns sTemplatePathPreference 
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Security Object 

Public Methods 

The following API is exposed by the Security Object and is used by the 
application for security checking: 

5 

• IsOperAuthorized(vMsg As Variant, nOperations As cmOperations, 
vContext As Variant) as Boolean 

This API will return true or false depending on what is returned from the 
10 business rule functions to determine user access levels. This API is called on 

two situations: 

1. When setting the initial state before loading the form. If a security 
requirement exists, IsOperAuthorized is called for the appropriate 

15 operation. 

2. After any relevant change on the UI state. For example, when a sensitive 
claim is highlighted on the Task Assistant window. A relevant change is 
one which brings the need for a security check. 

20 The valid values for the enumeration and the correspondent context data are: 

■ cmMaintainFormsCorr (none) 

■ cmRunEventProcessor (none) 

■ cmWorkOnSensitiveClaim (a Claim object) 

■ cmMaintainPersonalProfile (none) 
25 ■ cmMaintainWorkplan (none) 

■ cmDeleteFileNote (a File Note object) 

■ cmMaintainTaskLIbrary (none) 

■ cmMaintainOrg (none) 
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Server Security APIs 

5 • IsSVCOperAuthorized(vMsg As Variant, sOperations As String , vContext As 
Variant) as Boolean 

This API is called by every method on the server that persists data or can 
potentially access sensitive data (reactive approach). 

10 

■ IsOperAuthorized(vMsg As Variant, nOperations As cmOperations, vContext 
As Variant) as Boolean 

This API is available for those cases where a proactive security check is 
15 needed on the server. 



Implementation Examples 

20 

The following examples show some ways to implement the options described 
above: 

Client 

25 

• Business Logic 
IsOper Authorized 



30 Let's consider the case of the Task Assistant window, where the user should 

not be allowed to view any information on a sensitive claim if he/she is not 
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the claim performer or the performer's supervisor. The following code would 
be at the Controller: 



Private Sub TaskTree_NodeChanged ( . . . . ) 

myController . SetCurrentTask 

myController .SetState 
End Sub 

Private Sub SetState ( ) 

Dim obj Security as Object 
Dim vContext (1) as Object 

Set objSecurity = taaApp. taoArch. obj Security 

vContext (0) = CurrentClaim 
vContext ( 1 ) = CurrentTask 

tlbEditlcon. Enabled = 

obj Security. I sOper Authorized (vMsg ; cmWorkOnSensitiveClaim, 

vContext ) 

End Sub 

Let's consider the case of the Maintain Correspondence Search window 
where only a user who is a Forms and Correspondence Librarian should be 
allowed to delete a template. The following code would be at the Controller: 



Private Sub SetWindowMode ( ) 
Dim objSecurity as Object 

Set objSecurity = taaApp. taoArch. obj Security 



tlbEditlcon. Enabled = objSecurity. IsOperAuthorized (vMsg, 
cmMaintainFormsCorr ) 



40 Server 



* SQL Filtering: 
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Let's consider the example of the Draft File Note window, where a user can 
only look at the draft file notes on which he/she is the author. At the 
controller, one would have: 



Public Sub GetDraf tFNotes ( ) 
Dim objCP as Object 

Set objCP = taoArch.objClientProfile 
Dim fntCCA as Object 

Set fntCCA = taaApp.taoArch.GetCCA(cmCCAFileNote) 

Call fntCCA.GetADraftFNotefvMsg, objCP . sOrgUserld, colFNotes) 
End Sub 

And at the Component, the SQL statement would be: 

Select nFNoteld, 
sFNoteAuthor, 
dFNoteFinal , 



From File Note 

Where sFileNoteSts = >D' 

And sFNoteAuthor = sAuthor 



Task Engine Application 



This application runs on the server as a background process or service with no 
30 direct interaction with Client applications, so it doesn't need any GUI related 
security. Basically, its main actions are limited to the generation of new tasks in 
response to externally generated events or, more specifically, it: 



• Reads static information from the Task Template tables; 
35 • Reads events from the Event tables; 

• Inserts tasks on the Task table. 



In this sense, its security is totally dependent on external entities as described 
below: 

40 
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• The Task Library application is the entrance point for any changes on the 
Task Template database tables. It will make use of the options described 
above in order to fulfill its security requirements. 

• Events are generated from legacy applications, so the Task Engine relies 
5 completely on the security implemented for these applications in order to 

control the generation of events. 

• Another level of security for event generation relies on the Database 
authorization and authentication functions. Only authorized components 
have access to the database tables (this is valid for all the other 

10 applications as well). 



CLAIM FOLDER 

Definition 

15 The Claim Folder manages claim information from first notice through closing 
and archiving. It does this by providing a structured and easy to use interface that 
supports multiple business processes for handling claims. The information that it 
captures is fed to many other components that allow claims professionals to make 
use of enabling applications that reduce their workload. Because physical claim 

20 files are still required, the claim folder provides capabilities that support physical 
file tracking. It works with the LEGACY system to support all the capabilities 
that exist within the current system. 



The primary processes supported by the Claim Folder are: 

25 

• First Notice of Loss 

The Claim Folder is the primary entry point for new loss information. Claim 
files exist in the Claim Folder before they are "pushed" to the LEGACY 
system to perform financial processing. 
30 • Claim Inquiry 
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Claim Folder supports internal and external inquires for claim 
information. The folder design allows quick access to various levels of 
information within the claim for many different reasons. 

• Initiation of Claim Handling 

5 The Claim Folder provides initial loss information to the claim 

professional so they may begin the process of making first contacts with 
appropriate participants in the claim. It allows them to view and enter 
data received through their initial contacts and investigation. 

• Investigation and Evaluation 

10 The Claim Folder provides access to detailed information needed for the 

investigation and evaluation process. It allows the claim handler to 
navigate between all the applications and information they need to 
support these processes. 

• Identifying Claim Events 

15 The Claim Folder identifies critical events that occur in the life of a claim, 

such as a change of status, which can trigger responses in other 
components to perform automated functions, like triggering tasks in the 
Task Assistant. 

• Managing the Physical File 

20 The Claim Folder supports better tracking capabilities for the physical files 

that go along with the electronic record of a claim. 



Value 

25 By capturing detailed information on claims, the Claim Folder tries to improve 
the efficiency of claim professionals in many ways. First, because the 
information is organized in a logical, easy to use format, there is less digging 
required to find basic information to support any number of inquiries. Second, 
the Claim Folder uses its information to support other applications like Forms 

30 and Correspondence, so that claim information does not have to be reentered 



-140- 



every time it is needed. Third, it provides better ways to find physical files to 
reduce the time required finding and working with them. Beyond this, there are 
many other potential uses of claim folder information. 

5 The Claim Folder also tries to overcome some of the current processing 

requirements that the LEGACY system imposes such as recording losses without 
claims, requiring policy numbers for claim set-up, requiring reserves for lines, 
and other restrictions. This will reduce some of the low-value added work 
required to feed the LEGACY system. 

10 

Finally, the Claim Folder organizes and coordinates information on participants 
and performers so that all people involved in a claim can be identified quickly 
and easily. 

15 Key Users 

Although claim professionals are the primary users of the Claim Folder, any 
claims professional can utilize the Claim Folder to learn about a claim or answer 
an inquiry about a claim. 

20 Component Functionality 

Because the Claim Folder is the primary entry point for new claims, it needs to 
capture information necessary to set-up new claims and be able to pass the 
information to the LEGACY system. Once the information is passed, the 
LEGACY system owns all information contained in both systems, and it is 
25 uneditable in the Claim Folder. However, the Claim Folder has more information 
than what is contained in the LEGACY system, and therefore allows certain 
information to be entered and modified once the claim is pushed to the LEGACY 
system. 
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The Claim Folder decomposes a claim into different levels that reflect the policy, 
the insured, the claim, the claimants, and the claimant's lines. Each level has a 
structured set of information that applies to it. For example, the claim level of the 
claim has information on the claim status, line of business, and performers. An 
individual line has information which includes the line type, jurisdiction, and 
property or vehicle damages. The claimant level contains contact information as 
well as injury descriptions. 

The information at each level is grouped into sections for organization purposes. 
Each level has a details section that includes the basic information about the 
level. 

The key levels on the Claim Folder and their information sections are: 

• The Policy Level: Details and Covered Auto for auto claims, Covered 
Property for property claims and Covered Yacht for marine claims. 

• The Claim Level: Details, Facts of Loss, Events, Liability. Liability is 
considered part of the Negotiation component and described there. 

• The Participant Level: Details and Contact Information. For claimants, 
additional sections are shown to display, Events, Injury and Disability 
Management. The participant level is discussed in the Participant 
Component. 

• The Line Level: Details, Damaged Vehicle for vehicle lines, Damaged 
Property for property lines, Damaged Yacht for marine lines, Events, 
Damages, and Negotiation. Damages and Negotiation are considered part 
of the Negotiation component and described there. 

Events are triggered in the Claim Folder by performing certain actions like 
changing a jurisdiction, identifying an injury, or closing a line. Other general 
events are triggered in the Event Section on most levels by clicking the one that 
has occurred. These events are processed by the Event Processor and could 
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generate any number of responses. In one embodiment of the present invention, 
the primary response is to trigger new tasks in the Task Assistant for a claim. 



User Interfaces 
Claim Folder UI 

Policy Level - Policy Details Tab 
Policy Level - Covered Vehicle Tab 
Policy Level - Covered Property Tab 
Policy Level - Covered Yacht Tab 
Claim level - Claim Details Tab 
Claim level - Facts of Loss Tab 
Claim level - Events Tab 
Claim level - Liability Tab 
Line level - Line Details Tab 
Line level - Damaged Property Tab 
Line level - Damaged Auto Tab 
Line level - Damaged Yacht Tab 
Line level - Events Tab 
Line level - Damages Tab 
Line level - Negotiation Tab 
Task Assistant 
File Notes 
Claim History 
Search Task Template 
Search for Correspondence 
Find Claims 
Version 7 
View File Folder 
Print Label 
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CLAIM FOLDER TREE AND MENU DESIGN 

5 

Claim Tree 

The claim tree in the Claim Folder window decomposes the claim into policy, 
insured, claim, claimant, and line levels depending on the specific composition of 
the claim. 

10 

The policy level is always the first node in the claim tree and is identified by the 
policy number. Before the policy number is entered, the field is listed as 
"Unknown". If a claim is uncoded, the field is listed as "Uncoded". Selecting 
the policy level brings up the policy level tabs in the body of the Claim Folder. 

15 

The insured level is always the second node in the claim tree and is identified by 
the insured's name. Before the insured is identified, the field is listed as 
"Unknown". Selecting the insured level brings up the insured participant tabs in 
the body of the claim folder. Only one insured is listed at this level as identified 
20 in the policy level tabs, however, multiple insureds can still be added. Additional 
insureds are shown in the participant list below the claim tree. 

The claim level is always the third node in the claim tree and is identified by the 
claim number. When the claim level is selected, the claim level tabs appears in 
25 the body of the Claim Folder. 

After the claim level, all claimants are listed with their associated lines in a 
hierarchy format. When a claimant is added, a node is added to the tree, and the 
field identifying the claimant is listed as "Unknown". Once a participant has 
30 been identified, partial or client, the name of the claimant is listed on the level. 
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When the level is selected, the participant level tabs for the claimant is shown in 
the body of the claim folder. 

Line levels are identified by their line type. Before a line type is selected, the line 
5 level is listed as "Unknown". When a line level is selected, the line level tabs for 
the specific line are shown in the body of the claim folder. 

There are several things that can alter the claim tree once it has been set up. First, 
if a claimant or line is deleted, it is removed from the claim tree. A claim that is 
10 marked in error does not change the appearance of the levels. Second, the claim, 
claimant, and line levels are identified by different icons depending on whether 
they are pushed to V7 or not. Third, when a line or claimant is offset, it is 
identified as such. 

15 Participant List 

The participant list box contains all the non-claimant and non-insured participants 
on the claim. (Claimants and insureds are shown in the claim tree and not 
repeated here.) Participants are shown with their name and role. When a 
participant is selected, the participant level tabs are displayed in the claim folder. 

20 

Claim Folder Menu Items 

The claim folder menus contain the actions that a user would need to perform 
within the claim folder. They can all be accessed through keyboard selection. 
The menu options become enabled or disabled based on the state of the Claim 
25 Folder. The Claim Folder can be in view mode or edit mode for a specific level 
in the Claim Tree. When the Claim Folder is in edit mode, most options are 
disabled until the user saves their changes and is returned to view mode. The 
enabling/disabling of menu options is also dependent on whether the claim or 
portions of the claim have been pushed to V7. 



30 



Claim Folder Tool Bar 

The tool bar represents common action that a user performs that can be easily 
accessed by clicking the appropriate icon. There are five groups of button on the 
Claim Folder tool bar that represent, in order, common activities, adding new 
5 items to a claim, launching utilities, performing V7 activities, and accessing help 
functions. The enabling/disabling of tool bar buttons follows the same logic as 
for menu items. 

Window Description 

10 



Control .Name 


'1 ype 


Description 


Default 
Value/Slate 


Claim Tree 


Tree View 


The Claim Tree lists the 
policy, insured, all of 
the claimants and their 
related lines in a claim 
tree format. 


The current claim 
tree structure for 
the selected 
claim. The claim 
level is selected 
and the claim 
level tabs are 
displayed. 


Participant List 


List View 


A list of all non-insured 
and non-claimant 
participants associated 
with a claim. 


All participants 
who are not 
claimants or 
insureds for the 
claim and their 
roles 


Edit Tool Bar Button 


Command Button 


Changes the tabs for the 
level selected in the 
claim tree or participant 
list view to edit mode. 


Enabled when 
claim is in view 
mode. 


Refresh Tool Bar 


Command Button 


Refreshes the current 


Enabled when 


Button 




claim, including all 
Participant and Line 
information. 


claim is in view 
mode. 


Find Tool Bar Button 


Command Button 


Opens the Claim Search 
window to allow the 
user to search for 
another claim 


Enabled 


Claim Allocation 


Command Button 


Opens the Claim 


Enabled when 


Tool Bar Button 




Allocation window. 


claim is in view 
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C ontrol Name 


'type 


Description 


Default 








Value/State 



Manage Physical File 
Tool Bar Button 

Declare Event Tool 
Bar Button 

Claimant Tool Bar 
Button 



Participant Tool Bar 
Button 



Command Button 



Command Button 



Command Button 



Opens the Manage 
Physical File window. 

Opens the Declare 
Events window. 

Adds claimant and 
opens Participant tabs in 
edit mode for entry of a 
new claimant level node 



Command Button 



Line Tool Bar Button Command Button 



Assign Performer 
Tool Bar Button 

Print Screen Tool Bar 
Button 

Task Assistant Tool 
Bar Button 

File Notes Tool Bar 
Button 

Claim History Tool 
Bar Button 

Correspondence Tool 
Bar Button 



Adds a new participant 
and opens Participant 
tabs in edit mode. 
Adds line and opens 
Line tabs in edit mode 
for entry of a new line 
level node. 



Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. V7 limit 
for claimants is 
999, we will not 
edit this here. 
Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode and 
claimant context 
selected in claim 
tree. V7 limit for 
lines is 15 per 
claimant, this 
button will be 
disabled after 15 



Command Button 

Command Button 
Command Button 

Command Button 

Command Button 

Command Button 



Opens Assign Performer 
window 

Prints the current claim 
folder window. 
Launches Task Assistant 
for the current claim 

Launch File Notes for 
the current claim 

Launch Claim History 
for the current claim 

Opens Forms and 
Correspondence window 



Push to V7 Tool Bar Command Button Open the terminal 



Enabled when 
claim is in view 
mode. 
Enabled 

Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
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Control Name 


T> pe 


Description 


Default 








Value/State 



Make Payment Tool 
Bar Button 



Command Button 



Help Tool Bar Button 
Claim | Edit 



Claim | Refresh 

Claim | Find 
Claim | Save 



Claim | Claim Status | 
First Report 
Complete 



Claim | Claim Status | 

Assignment 

Complete 



Claim | Claim Status | 
Close 



Command Button 
Menu Option 



Menu Option 

Menu Option 
Menu Option 

Menu Option 
Menu Option 
Menu Option 



emulator window at the 
first V7 setup screen. 



Open the V7 PUEM 
screen in the terminal 
emulator window if a 
claimant or participant 
tied to one claimant is 
selected. Otherwise, 
display window that 
requires user to select a 
claimant. 
Opens Help 

Changes Claim tabs into 
Edit mode so that the 
user can make changes 
Refreshes the current 
claim, including all 
Participant and Line 
information. 
Opens the Claim Search 
window 

Save the claim level 
when it is in edit mode. 

Changes the status of 
the claim to 
"Unassigned" and 
creates First Report 
Complete Event. 
Changes the status of 
the claim to "Open" and 
creates Assignment 
Complete Event. 

Initiates the close claim 
process 



claim is in view 
mode and claim 
status is pre-push 
or open and there 
are new claimants 
or lines to push. 
Enabled when 
claim had been 
pushed to V7 and 
a participant is 
selected. 



Enabled 
Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled 

Enabled when the 
claim level is in 
edit mode. 
Enabled when 
claim is in view 
mode and claim 
status is "New". 

Enabled when 
claim is in view 
mode and claim 
status is 
"Unassigned". 
Enabled when 
claim is in view 
mode, V7 claim 
status is closed, 
and Millennium 
Claim Status is 
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Control Name 


Tvue 


Description 


Default 
Value/State 








not "Closed" or 








"Archived" 


Claim | Claim Status | 


Menu Option 


Changes the status of 


Enabled when 


Reopen 




the claim to "Open". 


claim is in view 








mode and 








"Closed" or 








"Archived". 


Claim | Claim Status | 


Menu Option 


Marks the current claim 


Enabled when 


Mark In Error 




and all of its lines in 


claim is in view 






error. Expires all 


mode, and not 






participants. 


pushed to V7. 


Claim | Allocate 


Menu Option 


Opens the Claim 


Enabled when 




Allocation window. 


claim is in view 








mode. 


Claim | Manage 


Menu Option 


Opens Physical File 


Enabled when 


Physical File 




window 


claim is in view 








mode. 


Claim | Declare Event 


Menu Option 


Opens Declare Event 


Enabled when 






window 


claim is in view 








mode. 


Claim | Close Claim 


Menu Option 


Closes current claim 


Enabled 


Folder 




folder window 




Edit | Cut 


Menu Option 


Move selected text to 


Disabled 






the clipboard 




Edit | Copy 


Menu Option 


Copy selected text to the 


Disabled 






clipboard 




Edit [ Paste 


Menu Option 


Paste text from the 


Disabled 






clipboard 




View | Collapse All 


Menu Option 


Collapses the claim tree 


Enabled 


View j Expand All 


Menu Option 


Expand the claim tree 


Enabled 


Policy | Edit 


Menu Option 


Opens policy tabs in edit 


Enabled when 






mode. 


claim is in view 








mode. 


Policy | Save 


Menu Option 


Save current policy tab 


Enabled when 






information. 


policy level is in 








edit mode. 


Participant | New | 


Menu Option 


Opens Participant tabs 


Enabled when 


Claimant 




in edit mode for entry of 


claim in view 






a new claimant level 


mode. 






node in the claim tree. 




Participant | New | 


Menu Option 


Opens Participant tabs 


Enabled when 


Insured 




in edit mode for entry of 


claim in view 






a new insured level node 


mode. 






in the claim tree. 
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Control Name 


Type 


Description 


Default 






Value/State 


Participant | New | 


Menu Option 


Opens Participant tabs 


Enabled when 


Other 




in edit mode for entry of 


claim in view 






a new entry in the 


mode. 






Participant list. 




Participant j Edit 


Menu Option 


Puts currently selected 


Enabled when 






participant tabs into edit 


claim is in view 






mode. 


mode and 








participant 








selected in tree or 








list box. 


Participant | Save 


Menu Option 


Saves information 


Enabled only 




changed on participant 


when a 






tabs and returns claim to 


participant level 






view mode. 


is in edit mode. 


Participant | Delete 


Menu Option 


Deletes selected 


Enabled only 




participant 


when claim is in 








view mode and 








participant is 








selected. 


Line | New 


Menu Option 


Adds new line to claim 


Enabled when 




tree and opens line tabs 


claim is in view 






in edit mode. 


mode, claimant 








has been selected, 








and limit of 15 








lines per claimant 








has not been 








exceeded. 


Line | Edit 


Menu Option 


Puts Line tabs into edit 


Enabled when 






mode so that the user 


claim is in view 






can change line details 


mode and line is 








selected. 


Line | Save 


Menu Option 


Save information 


Enabled when a 


entered on line tabs and 


line is in edit 






returns claim to view 


mode. 






mode. 




Line | Change Status | 


Menu Option 


Changes status of a line 


Enabled when 


Close 




in the claim folder to 


claim is in view 






"Closed" 


mode, a line is 








selected, the line 








is not closed, and 








its V7 status is 








closed. 


Line | Change Status | 


Menu Option 


Changes the status of 


Enabled when 


Reopen 


the line selected to 


claim is in view 
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Control Name 


Type 


Description 


Default 






\ alue/State 



Line | Change Status | Menu Option 
Mark in Error 



Line | Allocate Menu Option 

Performers | Assign Menu Option 

Performers | View All Menu Option 



Utilities | Print Screen Menu Option 
Utilities j View Task Menu Option 
Assistant 

Utilities | Create New Menu Option 
File Note 

Utilities | View Claim Menu Option 
History 

Utilities | Create Menu Option 

Correspondence 

Version 7 | Push Menu Option 

Claim 



Version 7 | Undo Menu Option 

Push 



"Open". 

Marks selected line in 
error. 



Opens the Claim 
Allocation window. 
Opens the Assign 
Performers window 

Displays all claim 
performers assigned to 
the claim in View 
Performer UI. 
Prints current screen. 
Opens Task Assistant 
window for current 
claim. 

Opens File Notes 
window for current 
claim. 

Opens Claim History 
window for current 
claim. 

Opens Forms and 

Correspondence 

window. 

Launches V7 to start the 
push process. 



Reverts claim to pre- 
push status. 



mode, a line is 
selected, and line 
is "Closed". 
Enabled when 
claim is in view 
mode, a line is 
selected, and line 
has not been 
pushed. 
Enabled 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled 
Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode and in "Pre- 
Push" status or 
open when there 
are unpushed 
claimants and 
lines. 

Enabled when 
claim is in view 
mode and status 
is "Push- 
Pending". 



Control Name 


"I ype 


Description 


Default 
Value/State 


Version 7 | Make 


Menu Option 


Open the V7 PUEM 


Enabled when 


Payment 




screen in the terminal 


claim had been 




emulator window if a 
claimant or participant 
tied to one claimant is 
selected. Otherwise, 
display window that 
requires user to select a 
claimant. 


pushed to V7 and 
a participant is 
selected. 


Help | Contents 


Menu Option 


Opens help file to 
content menu. 


Enabled 


Help | Search For 


Menu Option 


Open help file to search 


Enabled 


Help On 




window. 




Help | About 


Menu Option 


Opens window 


Enabled 




displaying information 
about the application. 





Window Details 



Control Name 


Initial 


l)i lault 


lab 






Hutton 


Order 


Claim Tree 


Yes 




1 


Participant List 






2 


Claim Menu 






3 


Edit Menu 






4 


View Menu 






5 


Policy Menu 






6 


Participant Menu 






7 


Line Menu 






8 


Performer Menu 






9 


Utilities Menu 






10 


Version 7 Menu 






11 


Help Menu 






12 



CAR Diagram 

Control Name \ction Response Short Mnemonic 

K_ 

Claim Tree Click • Highlights Node in 

Tree 

• Disable participant in 
list view if one selected 
previously 

• Shows related tabs in 
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Control .Name 


\ctiun 




Short 


Mnemonic 










Key 













All Text Fields 
Participant List 



Double Click 

Highlight 
Click 



Double Click 



Edit Tool B ar Button Click 



Refresh Tool Bar 
Button 



Find Tool Bar 
Button 



Claim Allocation 
Tool Bar Button 
Manage Physical 
File Tool Bar Button 
Declare Event Tool 
Bar Button 
Claimant Tool Bar 
Button 



view mode. 
Enable appropriate 
menu items and tool 
bar buttons. 
Level selected in tree 
enters Edit mode. 
Enable Cut and Copy. 
Highlights participant 
in list box 

Deselects level in claim 
tree if one selected 
previously 

Shows related tabs in 
view mode. 
Enable appropriate 
menu items and tool 
bar buttons. 
Participant selected in 
list view enters Edit 
mode. 

Changes the tabs for 
the level selected in the 
claim tree or participant 
list view to edit mode. 
Refreshes the current 
claim, including all 
Participant and Line 
information. 
Opens the Claim 
Search window to 
allow the user to search 
for another claim 
Opens the Claim 
Allocation window. 
Opens the Manage 
Physical File window. 
Opens the Declare 
Events window. 
Adds claimant and 
opens Participant tabs 
in edit mode for entry 
of a new claimant level 
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Control Name 


\ction 


Response 


Short 


Mnemonic 








HHHBh 


Key 













Participant Tool Bar Click 
Button 

Line Tool Bar Click 
Button 



Assign Performer Click 
Tool Bar Button 
Print Screen Tool Click 
Bar Button 

Task Assistant Tool Click 
Bar Button 

File Notes Tool Bar Click 
Button 

Claim History Tool Click 
Bar Button 

Correspondence Click 
Tool Bar Button 

Push to V7 Tool Bar Click 
Button 

Make Payment Tool Click 
Bar Button 



Help Tool Bar 
Button 
Claim | Edit 



Claim | Refresh 



Click 
Click 



node 

Adds new participant 
and opens Participant 
tabs in edit mode. 
Adds line and opens 
Line tabs in edit mode 
for entry of a new line 
level node. 
Opens Assign 
Performer window 
Prints the current claim 
folder window. 
Launches Task 
Assistant for the 
current claim 
Launch File Notes for 
the current claim 
Launch Claim History 
for the current claim 
Opens Forms and 
Correspondence 
window 

Open the terminal 
emulator window at the 
first V7 setup screen. 
Open the V7 PUEM 
screen in the terminal 
emulator window if a 
claimant or participant 
tied to one claimant is 
selected. Otherwise, 
display window that 
requires user to select a 
claimant. 
Opens Help 

Changes Claim tabs 
into Edit mode so that 
the user can make 
changes 

Refreshes the current 
claim, including all 
Participant and Line 



-154- 



Control Name 


Anion 


Response 


Short 

Cut 

Ke\ 


Mnemonic 
Key 








information . 






Claim | Find 


Click 








tr + 








Search window 






Claim | Save 


Click 














when it is in edit mode. 






Claim | Claim Status 


Click 




Changes the status of 






| First Report 






the claim to 






Complete 






Unassigned and 












creates First Report 












Complete Event. 






Claim | Claim Status 


Click 




Changes the status of 






| Assignment 






the claim to "Open" 






Complete 






and creates Assignment 












Complete Event. 






Claim | Claim Status 


Click 




Initiates the close claim 






Close 






process 






Claim | Claim Status 


Click 


# 


Changes the status of 






| Reopen 






the claim to "Open". 






Claim | Claim Status 


Click 










| Mark In Error 






and all of its lines in 










error. Expires all 












participants. 






Claim | Allocate 


Click 




Opens the Claim 












Allocation window. 






Claim | Manage 


Click 


• 


Opens Physical File 






Physical File 






window 






Claim | Declare 


Click 




Opens Declare Event 






Event 






window 






Claim | Close Claim 


Click 


# 


Closes current claim 






Folder 






folder window 






Edit | Cut 


Click 




Move selected text to 




Ctrl + X 
tr + 






the clipboard 






Edit 1 Copy 


Click 




Copy selected text to 




Ctrl + C 








the clipboard 






iiQ.it | .raste 


Click 


m 


Paste text from the 




Ctrl + V 






clipboard 






View | Collapse All 


Click 


• 


Collapses the claim tree 






View | Expand All 


Click 


• 


Expand the claim tree 






Policy | Edit 


Click 




Opens Policy tabs in 












edit mode 






Policy | Save 


Click 




Save policy 
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Control Name 


Action 




Short Mnemonic 
tut Key 








tabs to view mode. 




Participant | New [ 


Click 




Opens Participant tabs 




Claimant 






in edit mode for entry 










of a new claimant level 










node in the claim tree. 




Participant | New | 


Click 




Opens Participant tabs 




Insured 






in edit mode for entry 










of a new insured level 










node in the claim tree. 




Participant | New | 


Click 




Opens Participant tabs 




Other 






in edit mode for entry 










of a new entry in the 










Participant list. 




Participant | Edit 


Click 




Puts currently selected 










participant tabs into 










edit mode. 




Participant | Save 


Click 




Saves information 










changed on participant 










tabs and returns claim 










to view mode. 




Participant | Delete 


Click 




Deletes selected 










participant 




Line j New 


Click 




Adds new line to claim 










tree and opens line tabs 










in edit mode. 




Line | Edit 


Click 




_rUXS J— Hie taDS into CQ.lt 








mode so that the user 










can change line details 




Line | Save 


Click 




Save information 








entered on line tabs and 










returns claim to view 










mode. 




Line | Change Status 


Click 




Changes status of a line 




| Close 






in the claim folder to 








"Closed" 




Line | Change Status 


Click 


• 


Changes the status of 




| Reopen 






the line selected to 










"Open". 




Line | Change Status 


Click 


• 


Marks selected line in 




| Mark in Error 






error. 




Line | Allocate 


Click 


• 


Opens the Claim 





Allocation window. 
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Control Name 


Action 


Response 


Short 
Cut 


Mnemonic 


Performers | Assign 


Click 


• Opens the Assign 










Performers window 






Performers | View 


Click 


• Displays all claim 






All 




performers assigned to 










the claim in View 










Performer UI. 






Utilities | Print 


Click 


• Prints current screen. 




Ctrl+P 



Screen 
Utilities | View Task 
Assistant 

Utilities | Create 
New File Note 

Utilities | View 
Claim History 

Utilities | Create 
Correspondence 

Version 7 | Push 
Claim 

Version 7 | Undo 
Push 

Version 7 | Make 
Payment 



Help | Contents 



Click 

Click 
Click 
Click 



Click 



Help | Search For Click 
Help On 

Help | About Click 



Opens Task Assistant 
window for current 
claim. 

Opens File Notes 
window for current 
claim. 

Opens Claim History 
window for current 
claim. 

Opens Forms and 

Correspondence 

window. 

Launches V7 to start 
the push process. 
Reverts claim to pre- 
push status. 
Open the V7 PUEM 
screen in the terminal 
emulator window if a 
claimant or participant 
tied to one claimant is 
selected. Otherwise, 
display window that 
requires user to select a 
claimant. 
Opens help file to 
content menu. 
Open help file to search 
window. 
Opens window 
displaying information 
about the application. 
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Data Elements 



Literal 


Length Control 


Data Kntitv 


ltdit 


lOrror Handling 




Type 


Tie 


Rules* 





Claim Tree 

- Policy 

- Insured 



Participant List 
Box 



Tree 
View 
Tree 
View 
Node 
Tree 
View 
Node 



Tree 
View 
Node 
Tree 
View 
Node 



Tree 
View 
List 
View 



Policy 

Number 

(Policy) 

Participant 

Preferred 

Name 

(Insurance 

Involvement 

) 

Claim 

Number 

(Claim) 

Particiapant 

Preferred 

Name 

(Insurance 

Involvement 

) 

Line Type 

(Line) 

Participant 

Preferred 

Name and 

Role 

(Insurance 
Involvement 



Involvement 
Role) 



5 



Commit Points 

10 Claim | Save Menu Option - Saves all claim level data 

Policy j Save Menu Option - Saves all policy level data 

Participant j Save Menu Option - Saves all participant level data 
Line j Save Menu Option - Saves all line level data 

Claim j Close Claim Folder Menu Option - Prompts user to save changes 
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if in edit mode. 

CLAIM HISTORY 

5 Definition 

Claim history shows information in one user interface that is intended to include 
all the constituent elements of a claim file. The four types of history included in 
the component are searchable by common indexing criteria like participant, 
performer, and claim phase. A caption report can be produced which shows the 
10 history selected in a document format. 

Value 

Claim history provides the users with one common interface through which to 
view a large variety of information about the claim. It includes all history 
available on a claim, and is expanded as claim capabilities are built, like 
15 incoming mail capture. Users develop customized views of history based on any 
criteria the history can be indexed by, and these reports are saved as customizable 
Word documents. The way the history information is indexed provides quick 
access to pertinent data needed to respond to a variety of requests. 

Key Users 

20 All members of the claims organization can use claim history as a way to quickly 
see all activity performed on a claim. This utility increases the ability to locate 
key information regarding any claim. 

Component Functionality 

Claim history is a component that contains a simple process to retrieve history 
25 from the other components in the system. It contains no native data itself. Even 
viewing a history element is done in the component window where the item was 
first captured. 
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The second key process of claim history is to produce a caption report of all 
history elements according to the items the user wants to include. 

There are two user interfaces needed for this component that correspond to the 
5 two key functions above: 

• Claim History Search: This window utilizes the claim phase, 
participant, performer and history type fields on each history record to 
help the user narrow the search for specific history. 

10 • Caption Report: This report uses the functionality of Word to produce 

a report of each history item the user wants to see and its associated 
detail. Since the report is produced in Word, it can be fully 
customized according to many different needs. 

User Interfaces 
15 • Claim History Search 

• Caption Report (Word document, not UI design) 

20 

FORMS AND CORRESPONDENCE 

Definition 

The Forms & Correspondence component supports internal and external Claim 
25 communication and documentation across all parts of the claims handling 
process. 

The Forms and Correspondence - Create Correspondence function provides the 
ability to search for a template using various search criteria, select a template for 
30 use and then leverage claim data into the selected template. 
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The Forms and Correspondence - Template Maintenance function is a tool for the 
librarian to create, delete, and update Correspondence templates and their 
associated criteria. 

5 Some specific processes supported by Forms & Correspondence are: 

• Reporting of claims 

- to state/federal agencies, etc. at First Notice of Loss 

- internal requests for information 

• Advising Participants 
10 • Contacting Participants 

• Performing Calculations 

• Creating correspondence for claims or non-claims 
Value 

15 

The Forms and Correspondence component supports user in creating 
documentation. 

Leveraging information from the claim directly into correspondence reduces the 
20 amount of typing and dictating done to create forms and letters. The typical data 
available to the templates should include: author, addressee, claim number, date 
of loss, insured name, policy number, etc. A librarian adds and maintains 
standardized forms and letters in logical groupings made available for the entire 
company. 

25 

Key Users 

Claim employees are the primary users of the Forms and Correspondence 
component, but it can be used by anyone who has access to the system to create 
30 documents using existing templates. 
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Forms and Correspondence librarians use the system to create, update or remove 
templates. 

Component Functionality 

Forms and Correspondence - Create Correspondence 
5 1. Search for a template based on search criteria. 

2. Create a correspondence from a template using claim data. 

3. Create a correspondence from a template without using claim data. 

4. View the criteria for a selected template. 

5. View the Microsoft Word template before leveraging any data. 

10 

Forms and Correspondence - Template Maintenance 

1 . Search for a template based on search criteria. 

2. Create, duplicate, edit, and delete Correspondence templates and their criteria. 

3. Internally test and approve newly created/edited templates. 
15 4. Properly copy Word templates for NAN distribution. 



User Interfaces 

• Search for Correspondence 

• Correspondence Details 

• Associate Fields 

• Maintain Correspondence Search 

• Correspondence Template Information - Details tab 

• Correspondence Template Information - Criteria tab 

• Microsoft Word 



25 
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FILE NOTES 

Definition 

File notes captures the textual information that cannot be gathered in discrete data 
elements as part of claim data capture. They are primarily a documentation tool, 
5 but also are used for internal communication between claim professionals. Users 
can sort the notes by participant or claim phase (medical, investigation, coverage, 
etc.) in order to permit rapid retrieval and organization of this textual 
information. 

Value 

10 File notes speeds the retrieval and reporting of claim information. A file notes 
search utility with multiple indexing criteria provides claim professionals and 
supervisors with the ability to quickly find a file note written about a particular 
person or topic. The file notes tool utilizes modern word processing capabilities 
which speed entry, reduce error, and allow for important information to be 

15 highlighted. Furthermore, the categorization and key field search eases the 
process of finding and grouping file notes. Finally, file notes improves 
communication as they can be sent back and forth between those involved in 
managing the claim. 

Key Users 

20 All members of the claims organization can utilize file notes. External parties via 
RMS can view file notes marked General. This utility increases the ability to 
locate key information regarding a claim. Anyone who wants to learn more 
about a claim or wants to record information about a claim utilizes the file notes 
tool. 

25 Component Functionality 

File Notes searching is included as part of the claim history component which 
allows the user to search the historical elements of a claim file including tasks, 
letters, and significant claim change events. 
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The user interfaces that are needed for this component are: 

• The File Notes Search (part of Claims History component): This 
window utilizes the claim phase fields on the file notes record to help 
the user narrow the search for specific file notes. Also, it allows users 
to view all file notes that meet specified criteria in a report style 
format. 

• File Notes Entry: The window used to record the file note. It embeds 
a word processing system and provides the ability to categorize, 
indicate a note as company (private) vs. general (public), save the note 
as a draft or a final copy, and send the note to another person. 

User Interfaces 

• File Notes 

• Draft File Note Review 

• Participant Search 

• Performer Search 



20 ADDRESS BOOK 

Definition 

Address Book is the interface between the claims system and the Client database. 
The Client application is a new component designed to keep track of people or 
organizations that interact with RELIANCE for any reason, but claims are most 
25 likely the first application to use Client. The Address Book is accessed directly 
from the Desktop and from the Claim Folder. 

The Address Book meets several needs within the claim organization. Although, 
its primary function is to support the adding of participants to a claim, it acts as a 
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pathway to the Client database for searching out existing participants, and adding 
new people or organizations to the corporate database. 

The Client database maintains information on names, addresses, phone numbers, 
5 and other information that always applies to a person or organization no matter 
what role they play on a claim. 

Value 

Address Book provides a common definition of people or organizations that 
10 interact with RELIANCE, and therefore provides a much more efficient means of 
capturing this information. Each Client database entry provides the ability to link 
a person or organization to all the different roles that they play across the 
organization, and therefore makes retrieving information on a client by client 
basis quick and easy. 

15 

There are many benefits to RELIANCE by having a common address book. 
Information on people and organizations is leveraged into other activities like 
enabled tasks that lookup a client's phone numbers when a call needs to be made. 
Information that has been redundantly stored in the past can be entered once and 
20 reused. Once all areas of RELIANCE use the Client application, different areas 
of the company can share definitions of individuals and organizations. 

Component Functionality 

Address Book allows users to add, edit and delete records from the Client 
25 database. It also provides a robust search facility, including phonetic name 
searches to find people contained in the Client database. 

There are two primary user interfaces for the Address Book: 
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• Find Address Book Entry - This is a search window that allows a user 
to find records in the Client database using names, addresses, phone 
numbers, and other identifiers. From this window, specific records 
can be selected and attached as participants on claims. 

5 • Maintain Address Book Entry - This window allows users to add or 

edit information about a client by specifying their names, addresses, 
phone numbers, email information, and identification numbers like a 
SSN or TIN. 

10 The Address Book is created concurrently with the Client application to make 
sure that a consistent design approach is followed. 

Key Users 

All members of the claim organization use the Address Book to look up 
15 information on people and organizations in the client database. Those who set up 
and handle claims use the Address Book to identify participants. 

User Interfaces 

• Find Client 

20 • Maintain Client 



INDEX 

Definition 

25 

The Index, or Claim Search, component provides the ability to locate claims 
within the system using various search criteria. The criteria cover a wider variety 
of search capabilities than exist today including, but not limited to, claim 
performers, participants, phonetic name searches, addresses, roles, offices, and 
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lines of business. The search results display selected claim, participant, and 
performer data to help identify each claim. 

The Index component also allows easy navigation to various claim components 
5 like the Claim Folder, once a claim has been identified. It can be accessed from 
the Desktop and from any open Claim Folder. 

The Index component is designed to support several business processes within 
the claim organization. Its functions are critical to improving claim staff 
10 productivity and customer service in the following areas: 

• Matching Mail 

The capabilities of the Index search make it easier to identify the 
claim a piece of mail belongs to based on criteria used to identify 
15 claims in forms, correspondence, and bills. The performers for a 

claim can also be identified for mail routing purposes. 

• Phone Inquiries 

This window is the primary point to handle incoming phone inquiries 
for any claim. Users can find claims quickly without having to burden 
20 the caller with requests for additional information. 

• Duplicate Claims 

Prior to setting up new claims, checks can be done to ensure that the 
claim has not already been entered into the system. The additional 
search capabilities provide a greater assurance that duplicate claims 
25 will not be entered. This reduces the need to delete or merge claim 

records. 

• Fraud Identification 

Because claims can be searched easily by participant and other 
criteria, fraud questions can be easily researched. This is not the 
30 primary purpose of this component, however. 
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Value 

Index reduces the time required to find existing claims, and also reduces potential 
rework from not finding claims when they are needed for matching mail or 
5 duplicate checks. 

Key Users 

Claim employees are the primary users of the Index window, but it can be used 
by anyone who has access to the system to access claims without having to 
10 memorize tracking numbers. 

Component Functionality 

Index is primarily a robust search engine that quickly and efficiently searches for 
claims. It is not a component that stores its own data, as it is primarily focused 
15 on pointing users more quickly and directly to claim data. 

Index is composed of one search window that follows the format of all other 
search windows in the system. 

20 User Interfaces 

• Find Claims 

25 INJURY 
Definition 

The Injury component captures versions of a claimant's injuries as they progress. 
This window captures injury information in the form of discrete data fields, 
reducing the need for free form text file notes. Capturing data, instead of text, 
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allows the injury to be closely tracked and quickly reported. The data can also 
serve as feedback statistics, i.e. for building best claims practices and in risk 
selection. The preferred method of identifying and documenting injuries is the 
ICD-9 code. The user can enter or search for the ICD-9 code using descriptors or 
5 numbers. 

Value 

Data on every injury is captured and summarized in a consistent, accessible 
10 format, making recording and reviewing the case considerably less time 
consuming and more organized, allowing the adjuster to focus on desired 
outcomes. This "snapshot" of the current status and history of an injury greatly 
facilitates handing off or file transfers between claim professionals. Additionally, 
the discrete data field capture enables the use of events to identify action points in 
15 the lifecycle of a claim that has injuries. 

Key Users 

All members of the claims organization can utilize the Injury component. This 
component increases the ability to locate and summarize key information 
20 regarding an injury. 

Component Functionality 

Injury is an aspect of participant information, which is related to the claimant 
participants on the claim. The participant component relates clients to all other 
25 claim-related entities. Information on injuries will be related to participant 
records and displayed at the participant level information in the Claim Folder. 
New entities are needed to implement injury data capture: injury and ICD-9 
search. The Injury component interacts with five other components: Claim 
Folder-which contains Disability Management data about a claimant; Participant- 



which lists the individuals associated with the claim; as well as File Notes, Task 
Assistant and the Event Processor. The injury component also uses Microsoft 
WORD to create a formatted, historical injury report for a particular individual. 

The user interfaces that are needed for this component are: 

• Injury: This is the primary injury window which captures basic injury 
report data, including: the source of the injury report, the date of the 
injury report, a Prior Medical History indicator, and then a detailed list 
of the injuries associated with that report. The detailed list includes 
discrete fields for the following data: ICD-9 code, body part, type, 
kind, severity, treatment, diagnostic, a free form text description field, 
and a causal relation indicator. 

• ICD- 9: This is the search window for locating ICD-9 codes and 
associated descriptions. 

• Disability Management: This window contains a subset of participant 
data fields that enables more effective injury management. 

User Interfaces 

• Claim Folder - Participant Level - Injury Tab 

• ICD-9 Search Window 

• Claim Folder - Participant Level - Disability Management Tab 

NEGOTIATION 

Definition 

Figure 10 is an illustration of the Negotiation component of one embodiment of 
the present invention. Negotiation provides a single, structured template that is 
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supplemented by supporting views, to capture events regarding a negotiation. The 
negotiation interface 1000 captures key elements of a negotiation, such as a 
settlement target range, current demands and offers, and Supporting Strengths 
and Opposing Assertions of the claim. Negotiation information is gathered in 

5 discrete data elements 1002, enabling the capability to generate events 1006 
based on key attributes or changes in a negotiation. These events 1006 are then 
sent to a common event queue 1008. The negotiation component 1000 interfaces 
with the File Notes 1004 component to provide additional documentation 
capability, in a non-structured format. The negotiation template is supported by 

10 all other data contained in the Claim Folder. 

Value 

Data on every case is summarized in a consistent, accessible format, making 
15 recording and reviewing the case considerably less time consuming and more 
organized, allowing the adjuster to focus on negotiation strategy and desired 
outcomes. This "snapshot" of the current status greatly facilitates handing off or 
file transfers between claim professionals. Additionally, the discrete data field 
capture enables the use of events to identify action points in a negotiation. 

20 

Key Users 

All members of the claims organization can utilize Negotiation. This component 
increases the ability to locate and summarize key information regarding a 
25 negotiation. 

Component Functionality 

Negotiation is a type of resolution activity, which is part of the claim component 
30 of the claims entity model. The claim component is the central focus of the 
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claims entity model, because it contains the essential information about a claim. 
The claim component supports the core claim data capture functionality, first 
notice processes, and resolution activity for claims. The main types/classes of 
data within the claim component are: Claim, Claimant, Line, Claim History, 
Resolution Activity, Reserve Item, and Reserve Item Change. Three entities are 
needed to implement negotiation: resolution activity, claim and claim history. 
There is also interaction between the Negotiation component and the Task 
Assistant, File Notes and Event Processor components. 

The user interfaces needed for negotiation are: 

• Negotiation: This window captures demand and offer data, including: 
amount, date, type and mode of communication. The target settlement 
range, lowest and highest, is captured, along with strengths and 
weaknesses of the case. 

Supporting user interfaces, which are also part of the Claim Folder, include: 

• Liability (claim level tab): This window is used to document liability 
factors in evaluating and pricing a claim. The liability factors include 
percent of liability for all involved parties; form of negligence that 
prevails for that jurisdiction; theories of liability that the claim handler 
believes to be applicable to the claim. Used prior to developing 
negotiation strategy. 

• Damages (line level tab): This window provides the capability for 
pricing and evaluating a claim based on incurred and expected 
damages. Used prior to developing negotiation strategy. 



User Interfaces 
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• Claim Folder - Line Level - Negotiation Tab 

• Claim Folder - Claim Level - Liability Tab 

• Claim Folder - Line Level - Damages Tab 



5 ORGANIZATION 
Definition 

Figure 11 is a flow diagram of the operations utilized by the Organization 
component in accordance with one embodiment of the present invention. The 
Organization component 1100 allows common information for the people who 
10 perform work on claims to be stored, searched, and reused across all the claims 
they work. 



In one embodiment of the organization component 1100, all employee records 
are kept in a common database 1102 so that they can be attached to the specific 

15 claims they work, located in a claim database 1104. The common information 
that is kept on the employee record includes name, location, phone, and some 
minimal organizational context information like office or division. This is the 
minimum required to support the tracking of performers on claims. The employee 
information 1102 is then linked 1106 to the claim information 1104 and the 

20 databases are updated 1108. Having linked the employees 1102 with the claims 
1104 they are working on, the database can be searched by employee or claim 
1110. 



However, this version of the organization can be expanded to include 
25 organization relationships (specifically tracking where an employee falls in the 
organization structure), groups of individuals as performers for claim assignment, 
and claim allocation within the organization structure. These capabilities are to 
support any notion of caseload analysis, management reporting, or automated 
assignment that would need to be included. 



30 
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Value 

By tracking common definitions of employees across claims, indexing 
capabilities are improved and performers on claims are accurately tracked. 



5 Key Users 

The primary users of the organization capabilities are the administrative 
personnel who set up performers, as well as the technicians who track who is 
working a claim. 



15 



Component Functionality 

The design of the minimum scope of the organization component includes a 
search window to find employees in the organization and a detail window to see 
specific information on each employee. 

User Interfaces 

• Organization Entity Search 

• Add/Edit Organization Entity 



20 Participant 

Definition 

Figure 12 is an illustration of the Participant component in accordance with one 
embodiment of the present invention. Participant 1200 provides the link between 
25 claims and individuals and organizations stored in the Client database and 

accessed through the Address Book 1202. Participant links clients to claims 1204 
by defining the roles that they play, e.g. claimant, driver, or doctor. It reuses the 
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information contained in the Address Book 1202 so that it does not have to be 
reentered for each participant. 

The participant component also allows linkages 1206 to be made between 
5 participant and to various items on claims. A doctor can be linked to the claimant 
they treat and a driver can be linked to the damaged vehicle they were driving. 

Once a participant has been added to a claim, additional information 1208 that is 
specific to that claim can be attached. This information includes injury, 
10 employment, and many other types of information that are specific to the role that 
a person or organization plays in a claim. 

The business processes primarily supported by Participant 1200 are: 

15 • Recording Involvement in a Claim 

There is a basic data capture requirement to keep track of individuals 
and organizations involved in a claim, and this is done most 
efficiently using the participant approach. 

• Recording Role Specific Information 

20 Address Book 1202 stores information that can be reused across 

claims, but the Participant component 1200 needs to maintain the 
information that is specific to an individual or organization's 
involvement in a specific claim. 

• Making Contact with Clients 

25 Because participant ties back to the common Address Book 1202, any 

contact information contained there can be quickly and easily 
obtained. 

• Forms and Correspondence 1210 

Leveraging address information into letters provides an efficiency 
30 enablement to all users who don't need to look up name and address 

information. 
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• Categorizing History Information 

Participants are used to categorize history items like tasks and file 
notes so that information relating to a single participant on a claim can 
be easily retrieved. 
5 • Claim Indexing 

Attaching participants to a claim allows the Index component to be 
more effective in the processing of claim inquires. 

Key Users 

10 The primary users of the Participant components 1200 are those who work 

directly on processing claims. They are the ones who maintain the participant 
relationships. 

Claims professionals who deal with injuries use the Participant tabs in the claim 
15 folder to track injuries and manage disabilities for a better result on the claim. 

Value 

Because the Participant component 1200 only seeks to define the roles that 
individuals and organization play across all claims, there is no redundant entry of 
20 name, address, and phone information. This is all stored in the Address Book 
1202. 

The number of potential participant roles that can be defined is virtually limitless, 
and therefore expandable, as the involvement of additional people and 
25 organizations needs to be captured. 



Component Functionality 
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Most participant functionality is executed within the context of the Claim Folder. 
The Claim Folder contains participants levels in two ways. First, claimants are 
shown in the claim tree on the left-hand side of the window. Below this, other 
participants are shown in a list. Selecting any participant displays a set of 
participant information tabs that displays the following information: 

• Participant Details - Basic information about the role that a 
participant plays in a claim and all the other participants that are 
associated to it. 

• Contact Information - Information from the Address Book on names, 
addresses, and phone numbers. 

• Injury - Specific information on the nature of injuries suffered by 
injured claimants. 

• Disability Management - Information on injured claimants with 
disabilities. 

Only the first two tabs will be consistently displayed for all participants. Other 
tabs can appear based on the role and characteristics of a participant's 
involvement in a claim. 

Adding or editing participant role information is actually done through the 
Address Book 1202 search window. The process is as simple as finding the 
Address Book 1202 record for the intended participant and specifying the role the 
participant plays in the claim. Once this is done, the participant will be shown in 
the Claim Folder, and additional information can be added. 

The notion of a participant is a generic concept that is not specific to claims 
alone. It is a based on design pattern that can be expanded as additional claims 
capabilities are built. Any involvement of an individual or an organization can be 
modeled this way. 
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User Interfaces 

• Participant Level - Participant Details Tab 

• Participant Level - Contact Information Tab 

• Participant Level - Events Tab 

• Participant Level - Injury Tab (Injury Component) 

• Participant Level - Di sability Management Tab (Inj ury Component) 

• View Participant List 



PERFORMER 

Definition 

The Perforer component allows organizational entities (individuals, groups, 
offices, etc.) to be assigned to various roles in handling the claim from report to 
resolution. The Performer component is utilized on a claim-by-claim basis. 

A performer is defined as any individual or group that can be assigned to fulfill a 
role on a claim. 

The Performer component supports the assignment processes within the claim 
handling process. This goes beyond the assignment of claim at FNOL. This 
component allows the assignment of work (tasks) as well. 

Some specific processes supported by Performer are: 

• Assign claims 

identification of different roles on the claims in order to assign the claim 
(Initiate Claim - DC Process work) 

• Keeps roles and relationships of performers within claims 

• Assigning tasks 
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• Reassignments 

• Supports Initiate claim process - assignment 

• Search mechanism for employees, offices 

• All performers should be in the Organization component 
5 • Provides history of assignments 

Value 

The Performer component allows the assignment of roles or tasks to individuals 
or groups. The data about performers resides in a common repository: the 
Organization component. 

10 

The Performer component reduces the time required to find employees, teams or 
any potential performer, and ensures consistency of data. 

Key Users 

15 The primary users of the Performer component are those who work directly on 
processing claims. They are the ones who maintain the assignment of roles or 
tasks related to a claim. 

Component Functionality 

The Performer component supports an informational function and an assignment 
20 function. 

1 . View details for performers (employee, office, unit, etc.). These details may 
suggest organizational entity relationships but in no way define or maintain 
them. 

2. View all performers assigned to a claim, currently and historically (includes 
25 individuals, groups, offices, etc.) 

3. Assign performers to a claim - at the claim level, claimant, and supplement 
levels (including individuals, office, groups, etc.) 
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User Interfaces 

• Assign Performer 

• Performer Roles 

• View Performer List 

5 

TASK ASSISTANT 

Definition 

The Task Assistant is the cornerstone of a claim professional's working 
environment. It provides diary functions at a work step level that allow the 

10 management of complex claim events. It enables the consistent execution of 
claim best practices by assembling and re-assembling all of the tasks that need to 
be performed for a claim based on detailed claim characteristics. These 
characteristics come from regulatory compliance requirements, account servicing 
commitments, and best practices for handling all types of claims. The Task 

15 Assistant also provides mechanisms that automate a portion of or all of the work 
in performing a task to assist the claim professional in completing his or her 
work. Once a task is completed, the Task Assistant generates a historical record 
to document the claim handler's actions. 

20 The Task Assistant is... 

• A method for ensuring consistent execution of regulatory requirements, 
account servicing commitments and claim handling best practices 

• A source of automated assistance for claim professionals 

• An organization-wide communication tool within the context of a claim (it 
25 does not replace Lotus Notes). 

• A mechanism for making claims strategy common practice and sharing 
corporate experience 

• A diary application to keep track of claims 

• A historical tracking tool 
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• A way to get a claim professional' s or a team leader' s attention 

• A mechanism for making process changes in the organization quickly 

Within the Task Assistant, claim professionals have the ultimate control to 
5 determine if and when tasks need to be completed. They also have the ability to 
add tasks to the list to represent work they do that is not reflected in standard 
definitions of tasks in the system. This supports a vision of the claim 
professional as a knowledgeable worker who spends most of his or her time 
focused on a successful result through investigation, evaluation, and negotiation 
10 of the best possible outcome. 

Value 

The Task Assistant reduces the time required to handle a claim by providing the 
claim professional with the automatic scheduling of claim activity. It helps the 
15 claim professional remember, perform and record tasks completed for every 
claim. Completed tasks are self-documenting and remain part of the claim 
history. 

The Task Assistant also ensures the consistent handling of claims throughout the 
20 organization, and by doing so can significantly impact expenses and loss costs. 
Furthermore, it helps ensure regulatory compliance and the fulfillment of account 
promises. It supports the teamwork required in handling difficult claims as a 
structure communication mechanism. 

25 The automated enablements for tasks reduce the amount of time claim 
professionals have to spend on low value-added activities such as writing 
correspondence. They can therefore spend a larger amount of time investigating, 
evaluating, and negotiating each claim. 



Key Users 

While claim professionals are the primary users of the Task Assistant, others use 
the application as well. The entire claims department utilizes the Task Assistant to 
structure work and communicate with one another. Team leaders use the Task 
Assistant to conduct file review and to guide the work of the claim professional. 
Administrative staff use the Task Assistant as a means to receive work and to 
communicate the completion of that work. Claim professionals use the Task 
Assistant to complete work and to request assistance from team leaders and 
specialty claim professionals. 

The Task Assistant requires a new type of user to set-up and maintain the variety 
of tasks that are created. A task librarian maintains the task library, which 
contains the list of all the standardized tasks across the organization. The 
librarian defines rules which cause tasks to be placed on task lists based on claim 
characteristics, dates which define when tasks are due, and task enablement 
through other applications. 

Component Functionality 

Figure 13 is a flow diagram of the operations utilized by the Task Assistant 
component of the present invention. The processing of tasks through the Task 
Assistant comprises the lifecycle of the task from its creation to its completion or 
deletion. In first operation 1300, the Task engine provides tasks to the Task 
Assistant. In the second operation 1302, the Task Assistant then displays the list 
of tasks provided by the Task Engine. In the third operation 1304, the user is 
allowed to add tasks and edit tasks provided by the Task Engine. The fourth 
operation 1306 occurs as the claim is processed. As the claim is processed, the 
user and the Task Engine determine when the various tasks are completed. When 
a tasks is completed, the fifth operation 1308 occurs. In the fifth 1308 operation, 
a historical record is generated for any tasks which is determined to be 
completed. 
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The key user interfaces for this component are: 

• The Task Assistant: This is the utility that supports the population, 
execution, and historical tracking of tasks. It allows users to perform 
tasks, complete tasks, and remove tasks that have been automatically 
added. 

• The Task Workplan: This user interface allows the user to strategize 
the plan for a specific claim. It shows tasks attached to their 
respective levels of the claim including lines, participants, and the 
claim itself. 

• Task Enablement Windows: There are many windows that can be 
added to enable task with other applications such as telephone 
support, forms and correspondence, and file notes. The number of 
potential task enablements is virtually limitless. 

• Task Entry : Allows a user to add new task that weren't automatically 
added to the task list to cover situations where the claim handler wants 
to indicate work to be done that is not reflected by the standard task 
definitions in the task library. 

Behind the functioning of the Task Assistant, the Task Engine continually 
evaluates messages sent from other components and determines based on the 
rules established by the task librarian, which tasks should be populated on the 
Task Assistant. Messages are sent to the Task Assistant when something 
significant occurs in another component. The messages contain the 
characteristics the Task Engine needs to evaluate in order to place the proper 
tasks on the task list. 

User Interfaces 

• Task Assistant 
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15 EVENT PROCESSOR / TASK ENGINE 

Definition 

Figure 14 is an illustration of the Event Processor 1400 in combination with other 
components of the system in accordance with on embodiment of the present 
invention. The Event Processor 1400 works behind the scenes of all claims 

20 applications to listen for significant events that have occurred in the life of 
various entities in the system like claims (but potentially many more like 
accounts or policies in the future). It determines what the response should be to 
each event and passes it onto the system component that will process it. The 
Event Processor is completely generic to any specific entity or event in the 

25 system and therefore enables automation based on an almost limitless number of 
events and responses that could be defined. 

Figure 15 is an illustration of the Task Engine 1404 in accordance with one 
embodiment of the present invention. The Task Engine 1404 processes the most 
30 common set of event responses, those that need to generate tasks 1406 based on 



events 1006 that have occurred. It compares the tasks that have been defined to 
the system to a set of claim criteria to tell which tasks should be added and which 
tasks should now be marked complete. 



5 The only interface the user sees to these components is the task library 1500, 
which allows task librarians 1502 to define the tasks and the rules that create 
them which are used by the Task Engine 1404. Working with these components 
is almost entirely a function performed by specialists who understand the 
complexity of the rules involved in ensuring events 1006 and tasks 1406 are 

10 handled properly. 

The event processor 1400 also manages the communication and data 
synchronization between new claim components and LEGACY claim systems. 
This single point of contact effectively encapsulates the complex processes of 
15 translation and notification of events between the two systems. 

Value 

The automated determination of event responses provides enormous benefits to 
system users by reducing the maintenance they have to perform in ensuring the 
correct disposition of claims. Users trigger events by the data they enter and the 
20 system activities they perform, and the system automatically responds with 
appropriate automated activities like generating tasks. 

The task generation rules defined in the Task Library provide an extremely 
flexible definition of claim handling processes limited only by the data available 
25 in the system on which task creation rules can be based. Process changes can be 
implemented quickly by task librarians, and enforced through the Task Assistant. 

Key Users 

Although all claim personnel directly benefit from the functioning of the event 
processor and task assistant, only specially trained users control the processing of 
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these components. Task Librarians using the Task Library user interface handle 
the process of defining new tasks and the rules that trigger them in the Task 
Engine. 

5 Operations personnel who ensure that all events are processed correctly and that 
the appropriate system resources are available to manage the throughput handle 
event processing. 

Component Functionality 

As shown in Figure 14, the Event Processor 1400 utilizes a common queue 208 
10 of events 1006 that are populated by any component 1402 of the system to 
identify what events have occurred. Working this queue, the Event Processor 
determines the appropriate response for an event and provides information to 
other components that need to process them. The Event Processor does not 
process any events itself and maintains clear encapsulation of system 
15 responsibilities. For example, an event that affects claim data is processed by the 
claim component. 

The Task Engine 1404 follows a process of evaluating events 1006, determining 
claim characteristics, and matching the claim's characteristics to tasks defined in 
20 the Task Library 1500. 

The key user interface for the Task Engine 1404 is the Task Library 1500. The 
Task Library 1500 maintains the templates that contain the fields and values with 
which tasks are established. A task template might contain statements like 
25 "When event = litigation AND line of business = commercial auto, then..." 
Templates also identify what a tasks due date should be and how the task is 
enabled with other applications. 
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User Interfaces 

• Search Task Template 

• Search Triggering Templates 

• Task Template Details 

5 

While various embodiments have been described above, it should be understood 
that they have been presented by way of example only, and not limitation. Thus, 
the breadth and scope of a preferred embodiment should not be limited by any of 
the above described exemplary embodiments, but should be defined only in 
10 accordance with the following claims and their equivalents. 



-187- 



CLAIMS 

What is claimed is: 

1 \/ A computer program embodied on a computer readable medium for 

2 / developing component based software capable of handling tasks, 

3 comprising: 
4 

5 a data component that stores, retrieves and manipulates data utilizing a 

6 plurality of functions; and 

7 

8 a client component including: 
9 

10 an adapter component that transmits and receives data to/from the 

11 data component, 
12 

13 a business component that serves as a data cache and includes 

14 logic for manipulating the data, and 
15 

16 a controller component adapted to handle events generated by a 

17 user utilizing the business component to cache data and the 

18 adapter component to ultimately persist data to a data repository, 
19 

20 wherein the client component is adapted for receiving a plurality of tasks 

21 that achieve a goal upon completion, allowing users to add new tasks that 

22 achieve the goal upon completion, allowing the users to edit the tasks, and 

23 generating a historical record of the tasks that are completed. 



1 2. The computer program as set forth in claim 1, wherein the provided tasks are 

2 generated based on characteristics of a scenario and a set of rules. 
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1 3. The computer program as set forth in claim 1, wherein the client component is 

2 further adapted for providing indications of levels of importance of the tasks. 

1 4. The computer program as set forth in claim 1, wherein the client component is 

2 further adapted for allowing the users to share the tasks with other applications. 

1 5. The computer program as set forth in claim 1, wherein the client component is 

2 further adapted for automating a portion of work needed to complete the tasks. 

1 6. The computer program as set forth in claim 5, wherein the portion of the work 

2 automated is writing correspondence. 

1 7. The computer program as set forth in claim 1, wherein the goal is insurance- 

2 related. 

1 8/ A computer program embodied on a computer readable medium for 

2 /treating a component based architecture capable of handling tasks, comprising: 

3 

4 a user interface form code segment adapted for collecting data from a user 

5 input; 
6 

7 a business object code segment adapted for caching data; 
8 

9 an adapter code segment adapted for transmitting data to a server; and 
10 

1 1 a controller component code segment adapted for handling events 

12 generated by the user interacting with the user interface code segment, 

13 providing validation within a logic unit of work, containing logic to 

14 interact with the business component, creating one or more business 

15 objects, interacting with the adapter component to add, retrieve, modify, 

16 or delete business objects, and providing dirty flag processing to notify a 

17 user of change processing; 
18 
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20 



21 



22 



19 



wherein the computer program is adapted for receiving a plurality of tasks 
that achieve a goal upon completion, allowing users to add new tasks that 
achieve the goal upon completion, allowing the users to edit the tasks, and 
generating a historical record of the tasks that are completed. 



1 



9. 



The computer program as set forth in claim 8, wherein the provided tasks are 



2 generated based on characteristics of a scenario and a set of rules. 

1 10. The computer program as set forth in claim 8, wherein the computer program 

2 is further adapted for providing indications of levels of importance of the tasks. 

1 11. The computer program as set forth in claim 8, wherein the computer program 

2 is further adapted for allowing the users to share the tasks with other applications. 

1 12. The computer program as set forth in claim 8, wherein the computer program 

2 is further adapted for automating a portion of work needed to complete the tasks. 

1 13. The computer program as set forth in claim 12, wherein the portion of the 

2 work automated is writing correspondence. 

1 14. The computer program as set forth in claim 8, wherein the goal is insurance 

2 related. 



2 




A computer program embodied on a computer readable medium for 
creating a component based architecture for allowing communication 
between a plurality of clients and a server in order to handle tasks, 



3 



4 



comprising: 



5 



9 



6 



7 



8 



one or more client components included with each client, each client 
component of each client adapted for communicating and manipulating 
data with a first data type, wherein the client component is adapted for 
receiving a plurality of tasks that achieve a goal upon completion, 
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12 



10 



11 



allowing users to add new tasks that achieve the goal upon completion, 
allowing the users to edit the tasks, and generating a historical record of 
the tasks that are completed; 



13 



14 



15 



one or more server components adapted for communicating and 
manipulating data with a second data type; and 



16 



18 



17 



one or more adapter components included with each client for translating 
data from the one or more client components to the second data type when 
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20 



19 



communicating data from the client to the server and further translating 
data from the one or more server components to the first data type when 
communicating data from the server to the client. 



1 16. The computer program as set forth in claim 15, wherein the provided tasks are 

2 generated based on characteristics of a scenario and a set of rules. 

1 17. The computer program as set forth in claim 15, wherein the client component 

2 is further adapted for providing indications of levels of importance of the tasks. 

1 18. The computer program as set forth in claim 15, wherein the client component 

2 is further adapted for allowing the users to share the tasks with other applications. 

1 19. The computer program as set forth in claim 15, wherein the client component 

2 is further adapted for automating a portion of work needed to complete the tasks. 

1 20. The computer program as set forth in claim 19, wherein the portion of the 

2 work automated is writing correspondence. 

1 21. The computer program as set forth in claim 15, wherein the goal is insurance 

2 related. 



1 METHOD AND ARTICLE OF MANUFACTURE FOR PROVIDING A 

2 COMPONENT BASED INTERFACE TO HANDLE TASKS DURING 

3 CLAIM PROCESSING 

4 

5 ABSTRACT 

6 

7 A computer program is provided for developing component based software 

8 capable of handling insurance-related tasks. The program includes a data 

9 component that stores, retrieves and manipulates data utilizing a plurality of 

10 functions. Also provided is a client component that includes an adapter 

1 1 component that transmits and receives data to/from the data component. The 

12 client component also includes a business component that serves as a data cache 

13 and includes logic for manipulating the data. A controller component is also 

14 included which is adapted to handle events generated by a user utilizing the 

15 business component to cache data and the adapter component to ultimately persist 

16 data to a data repository. In use, the client component is suitable for receiving a 

17 plurality of tasks that achieve an insurance-related goal upon completion, 

18 allowing users to add new tasks that achieve the goal upon completion, allowing 

19 the users to edit the tasks, and generating a historical record of the tasks that are 

20 completed. 
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